tag:blogger.com,1999:blog-59581938405110422292024-02-08T00:40:24.475-07:00Jyro DevelopmentsJyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.comBlogger110125tag:blogger.com,1999:blog-5958193840511042229.post-22740154293213741762017-12-23T13:51:00.000-07:002017-12-23T13:51:00.293-07:002017 In ReviewThis year has been a busy year. While it feels significantly less productive than the previous year about the same amount of effort has been put into my ongoing project. I want to keep this post short but realistically there isn't a ton to talk about and a heck of a lot more to get done.<br />
<br />
My first part of the last quarter was focused on reworking how terrain generation is going to work and get it capable of handling faster generation that the previous version I had. It helped my point out a few bugs I had in the previous version so it was very much worth the time. I've been working on my physics engine for most of the latter part of the last quarter with the odd piece being done for the actual project itself.<br />
<br />
I have come up with a robust and efficient solution to both physics and graphics that I am currently in the process of developing out the implementation. Nothing to really show as everything I've been doing is extensively unit and performance tested to make sure I'm not missing any details.<br />
<br />
At first, I thought my solution was going to allow for extremely fast physics, but the simple truth is that I have to compromise between accuracy and robustness. On the upside, I have a moderately efficient solution to solving complex convex polyhedral collisions. One of the challenges has been making it robust without comprising too much on performance. The solution I use is an approximation and by putting some limits on the physics engine I can make it stable and fast. The cost, however, is that I need to be careful with edge cases because it is only an approximate solution. I can very easily get myself into a situation where I get completely garbage solutions which would ruin the experience. The exciting part of what I have done with the physics can also be used by the graphics part of the engine which should allow me to scale up some of the neat lighting effects I plan to make use of.<br />
<br />
The plan for the next quarter is to finish off the physics engine and get all the parts of it working smoothly and integrated into the game engine. Then I'll be able to focus on getting the graphics engine switched over to the new system.<br />
<br />
All in all, I'm a little disappointed with where the project is at after a year of deciding to swap out the physics and graphics parts of the game. It certainly feels like a few steps backward, but each step forward I take now seems to be on a more solid foundation than before. However, that's about 10s of thousands of lines of code later.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-59699845469246214112017-10-12T20:47:00.003-06:002017-10-12T20:47:37.231-06:00The RewriteThere has been a very clear lack of posts this year, but not because I haven't been busting my butt. In my last post, I outlined what I wanted to accomplish and by what sort of time frame I was hoping to make it all happen. For the fun of it, I haven't looked at that post since I posted it in December 2016 and I feel like I can take a guess at where I wanted to be by this point.<br />
<br />
I believe the main thing I was hoping for was getting a custom physics engine up and running, and I had debated reworking the graphics engine. I think I was aiming to get a prototype going by the end of summer. (Something I certainly haven't been able to do). Now I'm going to take a look.<br />
<br />
Well, I certainly promised a few other things that I haven't finished yet. I also dramatically deviated from my outline. I think maybe the best approach is to outline what I have done in the last almost 10 months.<br />
<br />
<b><u>Physics</u></b><br />
This one was a big one, I knew going into it that I would be going deep into a very technically complex topic. There is a huge difference between knowing physics engines and actually writing one. It was a challenge, which I took on and am very happy with my result. I have a very unique physics engine that should be able to do everything I want. It is extremely robust and has absolutely no issues handling high-speed collisions flawlessly. I also have a nice automated test suite to make sure all the little parts tick correctly. I still haven't really built out the part that I originally intended for my game, but it isn't a high priority because have solved most of the difficult technical challenges.<br />
<br />
<b><u>Graphics</u></b><br />
As I had expected, I wasn't going to be doing a lot with client-side graphics. However, what I ended up doing was completely ripping out my old graphics and rewriting it and an engine from scratch. I was able to come up with something I believe can do high-quality real-time shadows. Time will tell if that truly ends up being the case, but it would be wonderful if it works out. I suspect it will be based on a few prototypes but we will see. I'm using a completely different rendering technique that I haven't seen used by anyone else as well.<br />
<br />
The motivating factor for doing my own graphics engine is because of the art style I've decided to go with: primitive object graphics. That doesn't mean low-polygon but it might have the look of it at times. I basically want to mix high-quality lighting with basic shapes to give it a very unique feel.<br />
<br />
<b><u>Interface</u></b><br />
I was planning to upgrade my graphics, what I wasn't planning on doing was reworking my integration with CEF. I ended up reworking my build system and dramatically simplifying it. I am now also able to make use of bleeding edge web technologies and have the ability to easily write automated tests anywhere in my software stack. I also have opened up the ability to debug every layer, which is going to be extremely useful for development. Effectively there is no guess and run, everything is testable and debuggable. The build system is straightforward and very easy to work with. Most of my frustrations with having a complex build process was having to figure out what went wrong and how to diagnose issues. Now everything is easy to debug and test.<br />
<br />
<b><u>Network</u></b><br />
A while ago, I was using a number of libraries for networking, but they lacked customization and seemed to carry a decent amount of overhead. Seeing how I basically reworked most of the engine/game I decided to rip out the network libraries and roll my own solution. Instead of going all low-level I settled on using Netty as the backbone for my implementations. I was able to whip up a TCP client/server, an HTTP server, and a WebSocket server in a few days. Each customized to match my needs for the engine. I now have a proper authentication layer and security around the client/server as well as considerable control over how everything operates. The best part of it was I basically tossed four libraries and now use just one which does everything I need and more.<br />
<br />
<b><u>Math</u></b><br />
Slightly unrelated, but I ended up extending my own linear algebra library because I was sick of dealing with terrible API and not being able to distinguish between immutable and mutable data structures. I even included a few useful types to deal with special cases and basically make the type system do correctness checks for me when performing calculations. All that dramatically simplified my work on the physics engine and made writing unit tests a breeze. I also wrote an arbitrary precision fixed-point library. This allows me to work at whatever precision I need, and I can use fixed-point for consistent number handling where it makes sense. I'm still using floating point for internal parts of the physics engine because it is just faster. I'm also using floating point for the graphics engine because that is just faster when dealing with it. However, I can now store and operate on numbers of any scale when I need to, something kind of important when working at solar system scales. Unfortunately, it takes up to 3 times longer to perform some calculations compared to a floating point but at other times is just as fast as floating point. Enough I won't use it for core calculations but I certainly can use it for intermediate values when transitioning between coordinate systems. It was something I was attempting to figure out previously, but now that I can scale to whatever precision I want and still run at fairly high performance there isn't any concern now.<br />
<br />
<b><u>Gameplay</u></b><br />
After all the previous work I've finally been able to get back to working on the game itself. I spent a ton of time working out engine design and am not able to crank out features related to the game. It is extremely easy and I've come up with an architecture that looks to be robust and extensible.<br />
<br />
<b><u>Administration</u></b><br />
I now am also using my own wiki for keeping track of architectural and development information (such as how to build the application). I wasn't sure what I wanted to do to keep track of it but figured it is better to use a real wiki with markdown over text files in the repo. I'm also recording and planning out my designs and thoughts in OneNote. It seems to work well, but I'm split on if google drive would simply work better. I'm also using a proper issue tracker now and making cards/organizing my backlog for cards. It really is just a glorified TODO list at this point, but it really helps me stay focused and provides a nice way to show progress.<br />
<br />
Based on my outline from before, I look like I'm roughly on track. Behind on a few things, but also pulled in a lot more than I was expecting. I will be continuing to work towards a playable demo (technically I have one but its nothing special) and as I work on it I'll be continually improving the physics and graphics engine. To the end of the backlog I go, one card at a time.<br />
<br />
<br />Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-26647324691356790292016-12-27T21:19:00.000-07:002017-10-12T21:16:08.822-06:00Looking back at 2016I figure with the end of 2016 coming closer it is time to look back at the year. One of the major differences this year has been my ongoing project. Not only has it taken up a large portion of my time, but it has also been a huge learning experience and refresher on things I had forgotten from my undergraduate engineering courses. I also have come to release that frequent updates to this blog are just not going to happen. It isn't because I don't want to post updates, but I tend to prefer working on my project than posting about it.<br />
<br />
Near the end of 2015, I wanted to get back into working on my own games. Shortly after finishing my master's program I was just mentally and psychologically exhausted. I had spent a significant amount of time playing games with a few friends and started to get an itch for making my own game. I was originally thinking to make a mobile game that I would want to play while taking transit. Something I could easily pause but also be complicated and requiring a good amount of problem-solving. At the time I had spent many hours playing Factorio, and so I was wanting to create a tower defense which required you to collect resources, manage power/communications, and fend off attacks from a moderately intelligent adversary.<br />
<br />
I got a very basic prototype done after a few weeks, but I started to envision a much bigger project. I was no longer taking transit simply because driving took about 1/5 the time. Together both of those factors made me change my mind. I began looking into technologies and libraries I could use to make it happen. Most of my development had focused on 2D but I had done some basic 3D work. In the end, I decided it would be worth my time to look into Unreal 4 vs Unity 5 as my experience with both engines had shown they had extremely robust rendering engines that would easily outdo anything I could create. They also had the nice feature of being able to support multiple platforms. The end result was my decision to go with Unreal 4, as the performance as my rendering engine exceeded what Unity 5 could deliver.<br />
<br />
After a few weeks of hacking together the general concept for what I wanted to create I through together a basic prototype in April 2016. Which you can take a look at below:<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/_D8oOc0oGRU" width="560"></iframe></div>
<br />
It was very simple but gave me the foundation for what I was going to build. As time went on I slowly started to build up a robust engine which delegated the rendering to Unreal. I still use the approach today and surprisingly it allows for rapid iterations and excellent utilization of the hardware.<br />
<br />
I had a short and bitter fight with Unreal's GUI frameworks in May of 2016 and decided to not bother fighting with them. Instead, I decided to stick a web overlay on top of the game canvas and use web technologies for my interface. On the surface, it seems more complicated, but it turns out to be significantly simpler and more productive. It also means I can create really good and solid looking user interfaces.<br />
<br />
Everything in my game is built to be networked and scalable. Over the summer I worked on pushing towards planetary sized worlds. Optimizing and reworking terrain generation, and pushing the limits of what can be done with today's technology. Eventually, I got terrain generation to a point where I could very quickly create terrain on the fly and travel at high speeds with fairly minimal lag. This is when I started to notice the limitations of my physics engine, more on that later.<br />
<br />
I then started working on making the terrain modifiable in September of 2016. I was originally planning to make use of an embedded database engine but I quickly came to realize that a database just isn't fast enough. That isn't to say the databases I tested were not high quality, or that they couldn't scale. It was mostly the fact I wanted to make them store and retrieve data with extremely low latency. I also didn't need to do a significant amount of querying so most of the advantages of a database were not helpful. I ended up writing my own storage system which allowed me to handle high levels of concurrency with low latency by keeping fragments of data in memory and using an asynchronous event-based approach. It worked really well and was straightforward when it came to implementing replication across clients. Something I only partially implemented, enough to prove it would work but then something else caught my attention.<br />
<br />
The physics engine was causing most of my headaches. Again, not the fault of the physics engine. It was doing a great job for what it was designed for. It just wasn't scaling well and caused a massive amount of headaches and complexity in my engine because I was having to delegate the game structures to something the physics engine could work with. I was also suffering from issues with high speeds and the occasional terrible collision response handling. I also had to write my own 'fix' for issues with tunneling because they solutions provided by the physics engine only worked most of the time. I could consistently break it.<br />
<br />
I had written my own physics engine for a 2D game many years ago. I was able to handle 17000 objects colliding at 60 fps using a few strategies I developed. I discovered the names of some of the strategies a few years later. It sort of hit me, there are no 2D physics engines that could handle that many objects and I have doubts any will be able to in the near future. Part of the reason is they are generalized solutions and can't make certain classes of optimizations in the problem space. Their generalizability makes them inefficient, which isn't a bad thing, it just means they are only limited to micro-optimizations. Such as using SIMD instructions, GPU acceleration, newer hierarchy structures, or newer algorithms. Whereas if I wrote my own I could tailor it to my application and only make the physics engine do the work that it actually needs to. I would also be able to deal with high-speed collisions and tunneling without having to fight against the physics engine.<br />
<br />
After reading a number of books on the subject, a few research papers, a thesis, and looking at various open source physics engines, I started thinking about how I could integrate a custom physics engine into my game engine. It was now December of 2016, but I wasn't ready to hook it up and swap out my existing physics engine interface. I wanted to start building a prototype physics engine. Very quickly I also realized that I would need a visual debugger to help me develop the engine and come up with test cases which I could use to verify correctness as I switch from naive implementations to heavily optimized solutions. I slapped together a quick visual debugger and was able to see my simulations. I also made sure I could easily step forward through time to make sure everything was behaving correctly.<br />
<br />
It sort of bothers me. I originally wanted to use a bunch of frameworks and libraries to make my life easier and allow me to develop the game faster. Instead, I kept having to deal with limitations and find workarounds for them and noticed my productivity decreased. I do have the fortunate benefit of not having a deadline and so I can take the hit of writing my own solutions where appropriate.<br />
<br />
This year has been a huge learning process, a year ago I would have never dreamed of writing my own physics engine or writing something instead of using a database for storage. I certainly would have thought by this point I'd have something playable instead of a sort of early tech demo. I guess that is the problem when you have to build your own technologies to solve problems others have yet to solve.<br />
<br />
Well enough about the past, where am I going next?<br />
<b>Short-term (Q1 2017)</b><br />
<br />
<ul>
<li>[Physics] Expand capabilities of the physics engine, such as supporting more shapes</li>
<li>[Physics] Deal with high-speed interactions and tunnelling</li>
<li>[Engine] Switch from existing physics engine to custom physics engine</li>
<li>[Graphics] Finish implementing client-side terrain updates</li>
</ul>
<br />
<b>Medium-term (Q2-Q3 2017)</b><br />
<br />
<ul>
<li>[Graphics] Determine what type of art style to use.</li>
<li>[Physics] Optimize custom physics engine including special handling for game</li>
<li>[Gameplay] Start working on core gameplay</li>
<li>[Interface] Revisit UI with updated technologies</li>
</ul>
<br />
<b>Long-term (Q4 2017+)</b><br />
<br />
<ul>
<li>[Gameplay] Get playable demo</li>
<li>[Graphics] Polish rough areas</li>
</ul>
<div>
<br /></div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-87576982349790366942016-09-11T16:22:00.001-06:002016-09-11T16:25:32.954-06:00Summer 2016 and some thoughtsIt only feels like it was only a few weeks ago I posted something here. However, time currently tells me it has been more than two months, so much for my biweekly posting plan. I've been pretty busy making more progress with my project but also been feeling a bit of a burnout and needing some time to relax. Most of the last two months has been dedicated to solving some of the harder problems in my project. Some of the challenges involved sketching out pages of design for weeks at a time without writing any code. Others were solved by writing tests or small prototypes.<br />
<br />
I had hit a complexity wall. Sometimes you get to a stage in a project where you know what you want to do but cannot wrap your head around the complexity of it. On paper it seemed straight forward, but once I started to code it I had to fight with making sure it was doing exactly what I wanted. I was entering into territory where writing tests was simply not sufficient. As it evolved and changed any tests I wrote were quickly obsolete and meaningless.<br />
<br />
It felt like I was back to when I was first learning programming and trying to create a text-based game. I was about 10 years old and had been coding for only a few months, but I had created a game that was about a 1000 lines long. It was my first experience of the complexity wall and my realization where writing software is hard and time consuming. Years later I hit it again, at the time I was working on creating fairly complex game inside of Warcraft 3. I was getting close to 10k lines of <a href="https://en.wikipedia.org/wiki/JASS" target="_blank">JASS2</a> (the scripting language for Warcraft 3).<br />
<br />
There was a realization; software is developed on a spectrum. On one end you can write code which is fragile and small, but can get the job done quickly. Or you can write code which is resilient and large, but takes a long time to get the job done. I noticed over the years how the fragile and small code is a common theme among programming contests and many successful projects. It is really attractive because it takes the least amount of time to get something done. In the case of programming contests it gives you more time to think about solving the problem and lets you finish the contest in less time. In the case of successful projects, it allows you to get the product out and start making money sooner.<br />
<br />
I've also seen the dark side of fragile and small code, one that is often ignored. I've seen many games start out good, push out features quickly, and start making money. Then a few years go by and the project ends up being abandoned because progress slows down to a grinding halt, bugs are constantly plaguing the game, and the money runs dry which forces the developer to stop supporting the game. You frequently hear the words 'rewriting', 'bug fixing', 'new systems', etc. If you don't believe me, look at Steam and a vast majority of the indie games... the ones you only heard small things about and the ones that haven't turned into wildly popular games (the ones that after a few years are still < 100k copies sold). It makes me wonder if we are going to have a repeat of the 'video game crash of 1983', mobile apps have not helped with this. Writing resilient and large code is not ideal when it comes to games either. It simply takes too long to get the product out the door, many game projects from start to 'release' tend to take a few years or less. Early access has helped but fragile and small software can also take advantage of early access.<br />
<br />
So what is ideal? Well, the short answer is nobody really knows. The long answer depends on what type of software you are producing. If you are writing flight software for an aircraft, or writing software for autonomous vehicles, or safety systems to support industrial applications, then writing resilient software with minimal bugs and high reliability is critical. If you are writing a mobile game, or a simple app for a device where bugs are not critical and the market is constantly shifting to the next hot thing, then getting your app out as quickly as possible is critical. You cannot escape the project management triangle:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fc/Project-triangle.svg/455px-Project-triangle.svg.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="196" src="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fc/Project-triangle.svg/455px-Project-triangle.svg.png" width="200" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
Indie developers really are stuck with 'Cheap' so there are really only 2 best case options:<br />
- Cheap & Fast, but not Good<br />
- Cheap & Good, but not Fast<br />
<div>
When I say 'good' I am not referring to the quality of the game, but the quality of the software produced for the game. When I say 'fast' I'm not referring to the game running well on low-end machines or getting high frame rates, but the game getting released sooner than later. Those with a keen eye will realize if a game is getting delayed it is because they are trying to go from Cheap & Fast to Cheap & Good. As far as I know, in software there is no feasible way to do it. You can go from Cheap & Fast to Fast & Good, but it seems to kill most indie games.</div>
<div>
<br /></div>
<div>
So where am I going with all this? Well, with my current project I find the Cheap & Fast to be unacceptable. Actually I generally stick to Cheap & Good, which typically means it takes a long time for me to write a project. It is also what turned me off from coding contests and coding competitions. The realization they promote writing terrible to maintain code and reward those who can make something work quickly even if the code itself is throw away. The problem is few want to invest the time in a contest or competition to have a competition for creating a robust system which scales and has a high quality. However, the real-world is that kind of competition and the success of a project is almost never on the quality of the software itself, but on the quality of the overall product in market. The issue is, low quality products can become popular and high quality products can end up never being profitable. However, when I think about it high quality products which do become successful tend to stay popular over the long term. I cannot think of any low quality products which have stood against the test of time. I believe that is why I tend to prefer the idea of a Cheap & Good project over Cheap & Fast project.</div>
<div>
<br /></div>
<div>
I've found a sort of way to cheat in the fast part, with two simple things: technology and architecture. It basically means my speed is limited to the technologies I choose. Which is why I'm continuously looking for better frameworks/libraries/languages to use. If I don't, then my development speed is constantly the same speed which really limits the types of projects I can take on. The other part is architecture, something which you must learn and experience to really understand. Part of the reason I am always working on projects on the side because it takes a long time to improve on if you don't build an understanding of the ways you can solve problems or improve your knowledge. It doesn't mean I am breaking the project management triangle, it just means I'm improving my overall resource capabilities. A diagram to visualize:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://docs.google.com/drawings/d/1j9wnGMkIeZ6VLqSGAVn2bJ_Lwkb4cBMEfpbL2ackoXE/pub?w=227&h=222" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://docs.google.com/drawings/d/1j9wnGMkIeZ6VLqSGAVn2bJ_Lwkb4cBMEfpbL2ackoXE/pub?w=227&h=222" /></a></div>
<div>
Essentially, you can never get into the fast area, but you can certainly get closer to it by improving your total resource capabilities. In the diagram this is going from the black circle to the white circle. Obviously getting to the white circle is never going to happen, but moving away from the black one happens every time you improve your tool-set, gain knowledge which helps you solve a problem, or find a better approach to the overall problem. Yes, every time you do one of those you will pay a little bit in the cost area, but the gains are higher productivity while maintaining high quality and keeping the overall cost of the project low.</div>
<div>
<br /></div>
<div>
A real-world example would be game engines. You could write your own, you could use Unity, Unreal, or another one. Every time you write your own there is a cost, the time it will take for you to write it. Unity and Unreal usually come with a price tag or take a slice out of your profits. The decision you need to make is deciding if the cost is worth the benefits. Sometimes using a framework adds additional development cost with no long-term benefits. Other times using a very popular and well maintained open source framework comes with minimal development costs and significant long-term benefits. It is a hard problem knowing when to write your own, when to stop using a framework and when to pick up a new one. The same can be applied to other aspects of software development, such as languages, design tools, development environments, deployment tools, build tools, source control, etc.</div>
<div>
<br /></div>
<div>
Sometimes I write my own, but it is usually for smaller components and typically I look into how others before me have solved the problem. Building on the knowledge and lessons learned from others will tend to be better than pretending you are an expert and writing your own solution in isolation. You can learn from mistakes without having to experience the mistakes first hand. Don't reinvent the wheel, but when you need to make some special custom wheel to solve your exact problem make sure you understand why the wheel shouldn't be square. Don't try to use a hammer for a screw. Picking a framework or library just because you are familiar with it doesn't mean it will help you solve your problem any faster. Maybe during the early stages you will see lots of benefits but over time you will start to notice the pains of the decision. You or the people who continue with the project will have to live with the pain of the decision you made.</div>
<div>
<br /></div>
<div>
After a summer of being low on the tangible productivity of my project, I still feel a very strong sense of accomplishment. I am working towards fleshing out some of the bigger and complex features of my project. I am writing them in a way I know it is very unlikely I will ever have to rewrite them. A fairly bold statement, but one I strongly believe in. I feel that if you spend the time understanding the problem and prototype out various solutions you will eventually arrive at a solution which will do everything you want it to and be extremely easy to expand or reuse. It doesn't need to be generalized, but it does need to be flexible enough so there is a straight forward way to get to your end goal(s). I think that is the advantage I have of being both the designer and the developer of my project. I know what I want, and I am the one working towards making it a reality.</div>
<div>
<br /></div>
<div>
A minor side note: It is a bit of a scary thought thinking about how a single large complex feature in my project took about 2 months to complete. Maybe a couple weeks less than that if I consider the time I took for vacation and just general down time.</div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-448590237691731882016-06-27T18:54:00.005-06:002016-06-28T17:42:53.467-06:00Playing with KotlinToday there are many JVM languages, and to be fair I have a strong opinion on most of them. My first non-Java JVM language was Scala, which I still have mixed feelings about. I was just very turned off by the language since it has many powerful features but when I was trying to make it my main language I was constantly plagued with issues of tool support for an IDE. Groovy did not impress me because I just simply cannot see the value in dynamic languages beyond smaller projects. I prefer a compiler catching an entire category of bugs and avoiding having to look at documentation to tell me what type my third-party library is returning to me or what types the parameters should be. It is why I really enjoy using auto for locals and lambdas in C++ and var in C#. Sometimes the type doesn't matter to me, or it is so blatantly obvious I don't see why I would need to declare it.<br />
<br />
Unfortunately, C# (or at least to my current knowledge) does not have the concept of constant local variables. I tend to like knowing up front if a variable is going to change it's value over the scope of the function, it means I have less things to think about as I'm evaluating code. Java is only just starting to dip it's toe into type inference, but as a whole the language is terribly verbose. Then on top of that you have a large part of the Java community that believes everything should be abstracted to the point of meaninglessness. If I need to look at more than a file or two to know what I am working with then there is simply too much abstraction. As they say, less is more, and being concise while maintaining clarity is a heck of a lot easier to maintain than abstracting away all the details. Naturally, if you are writing a public interface you should make it abstract though the extent to abstract really depends on the language and the need to maintain an ABI or API.<br />
<br />
I like functional features, but I'm still not set on using a functional language which is why I don't use Clojure (which again is dynamic so another point against it). Functional languages are good at solving some problems but can very overly verbose at solving others, where a loop and state would just be simpler. I played with Xtend for a while, and it seemed to fit right where I would like a language to fit. However, I got frustrated by how fragile the compiler was, and it was decently supported I just couldn't put faith behind it or trust that the project will be maintained for a long time. At the time I was using it I heard about Kotlin and I read a few things about it, but realized it hadn't been around for very long and the developers were not maintaining backwards compatibility. However, that all changed recently when they were preparing their release candidates for version 1.0 and at that point they would be backwards compatible. I was using Intellij after being a long time user of Eclipse, and to be fair having the ability to set Eclipse key bindings has made my transition to JetBrains' tool set very straightforward.<br />
<br />
I used Eclipse for almost 10 years, and over the years I have tried other IDEs for many different languages. I did use WebStorm for Javascript a few years back and was quite impressed by it. PhpStorm I more recently used and was continued to be impressed by how solid of an IDE the Intellij derivatives were. After giving Intellij another shot recently I was simply blown away at the quality and the performance of the IDE, especially with how easy it was to manage builds and libraries. Then I tried Kotlin. I was expecting to find Kotlin + Intellij similar to Xtend + Eclipse... and I couldn't have been more wrong. The experience so far after using it for about 8 months has been nothing but solid with the odd minor hiccup that were extremely easy to workaround or resolve. The issue tracker for JetBrains' products and seeing the responses and watching fixes has been very impressive.<br />
<br />
The only thing that really drives me nuts from JetBrains these days is Reshaper++ and Visual Studio... However, I feel most of the problems are from working on very large solutions in Visual Studio and not from the Resharper++ plugin. If I could make use of CLion for building with the Visual Studio tool chain I could only dream of how much more productive I would be in C++. I have debated trying to make everything work with QtCreator, which is a decent IDE, but I would rather spend the time coding than trying to make my tools work.<br />
<br />
Kotlin brings a number of things to the table that I just have a hard time finding with most other languages. The first thing is Java interoperability being treated as a first class citizen. This means using Java libraries is extremely simple and straight-forward. It also means using the JDK isn't frowned upon or difficult. I can reuse my knowledge from Java without having to learn yet another standard library. Kotlin supports extension functions and properties, which simply means using the JDK isn't difficult because it has been well extended by Kotlin to offer very use and powerful features that you simply don't have in other JVM languages. An example is converting between lists and arrays, something dead simple in Kotlin, but painful in Java and annoying in other languages.<br />
<br />
Type inference and null checking are my favorite features, but next on the list would be method and property extensions. I think an example is more useful here so let there be some example code:<br />
<br />
<pre>fun Double.abs(): Double = Math.abs(this)
</pre>
<br />
I will assume basic Java knowledge when talking about the Kotlin example code. The above is a function definition which extends the double type (notice I'm talking about double and not Double) to have a method called "abs". This method is defined as calling Math.abs on itself and returning the value. A few examples:<br />
<br />
<pre>println((3.0).abs()) // Prints 3.0
println((-2.0).abs()) // Prints 2.0
var x = 2.0 / -1
println(x.abs()) // Prints 2.0
</pre>
<br />
Now of course those familiar with Java will be freaking out about auto-boxing. My response is, there isn't any. The Kotlin compiler is pretty smart about that. It simply will replace the code to look roughly like:<br />
<br />
<pre>System.out.println(Math.abs(3.0)); // Prints 3.0</pre>
<pre>System.out.println(Math.abs(-2.0)); // Prints 2.0
double x = 2.0 / -1;
System.out.println(Math.abs(x)); // Prints 2.0</pre>
<br />
Coding in Kotlin really feels like Java but with a ton of syntactic sugar and a very smart compiler that will make intelligent choices for you. The above example is extremely simple, so let's see a more complicated example:<br />
<br />
<pre>
inline fun < reified T : Lock, reified R> T.useLock(task: () -> R) : R {
try {
this.lock()
return task()
} finally {
this.unlock()
}
}
</pre>
<br />
Unfortunately, I don't have a good syntax highlighter for Kotlin so you will have to accept pre-tagged code. The above probably looks pretty strange to a Java developer. You can probably guess it is a function definition. However, has the "inline" keyword on it, which means the Kotlin compiler will inline the function. The generic signature is two parts: first, "reified T : Lock" which means capture the type of T which is a subclass of Lock. In this case "java.util.concurrent.locks.Lock"; second, "reified R" which means capture the type of R. This means unlike regular Java generics, you actually have full type information of the generic parameters in this function and they are not erased. Now, if you are a Java developer your jaw should drop from that statement.<br />
<br />
The function extends all types of type T, which means anything that is or extends "java.util.concurrent.locks.Lock". You will need to import the definition to make use of it, but Intellij will automatically import it for you when you need it. The function will be called "useLock". It will take a lambda that has no parameters and returns a value of type R. The function itself returns a value of type R. The body should be fairly straight forward, it calls the lock and unlock method of the object's it extends and invokes the lambda in the critical section then returns the value from the invoked lambda. Long story short, you now have a method that applies automatic lock management to any locks you might consider using. So how would you make use of this? Well here is an example:<br />
<br />
<pre>
fun requestInputKey(key: String): Int {
return readLock.useLock({
inputKeyIdMap[key]
}) ?: writeLock.useLock({
val value = inputKeyIdMap[key] ?: currentKeyId++
inputKeyIdMap[key] = value
value
})
}
</pre>
<br />
I will leave it as an exercise to the reader to fully understand the details of the above code. However, it basically provides a read-write lock around a map. If the value key is defined in the map, it acquires the read lock and returns the integer that it maps to. If the key is not found in the map, it upgrades the read lock and acquires the write-lock. It rechecks the value, and if it doesn't exist it generates a new key value, assigns it to the map and returns the value. A comparable example in Java can be found on the <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html" target="_blank">JDK8 docs</a> page for ReentrantReadWriteLock, just look at the first example usage and compare it with the above code. The above example has significantly less code, and given the inlining and reified types it doesn't incur any overhead over the Java code. Moreover, I find it significantly easier to understand as I don't need to look at all the try/finally blocks or worry about null values. Nulls have to be explicitly specified and checked in Kotlin, so say goodbye to the famous NullPointerExceptions.<br />
<br />
There are a number of other useful extensions that can be written such as automatic resource closing (keep in mind Kotlin runs on Java 6), automatic memory management for objects which need to be explicitly deleted, suppression of exceptions, method reference parameters, and more. If you want to give it a try you can <a href="http://try.kotlinlang.org/" target="_blank">run it in the browser</a> (did I mention they are polishing their Kotlin to JavaScript compiler?). Months later, and thousands of lines of code later I continue to be impressed by the language and can't wait for what it will bring to the table in the future.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-62235908067879378732016-06-06T19:10:00.001-06:002016-06-06T19:10:16.807-06:00Multi-threaded, Networked, and Expanding<div class="separator" style="clear: both; text-align: left;">
Since my last post a significant amount of my time as been working through some of the fun and exciting challenges of working with Unreal 4 and fleshing out some of the larger architectural parts of the project. At some point I'm going to have to put a name on the project and while I have a working internal name that I currently use, I still haven't decided if I want to stick with it. Naming is hard. I sometimes find giving something a good name is harder than actually building the thing you are trying to name. So for now, I'm going to call it 'the project'.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
I can never stress it enough about how important architecture is when it comes to building an application. Throwing software together and expecting a good result is like taking a box full of puzzle pieces expecting the puzzle to assemble after you've shaken the box. Sure, over the lifetime of the universe it might happen, but lets be honest, nobody has time for that. I've seen many games go from being single-player to multi-player, go from being single-threaded to multi-threaded, or go from running well on a single-platform to running well on multiple platforms. It is possible, but doing it after the fact is a very huge investment compared to setting things up correctly the first time. I believe the term is technical debt, and when it comes knocking on the door for payment it has the tendency to stick around. One of the many design decisions I make when starting most projects is to figure out what my options are, and then more importantly how to make it happen with the least amount of effort from myself over the long term. If I look only at the short term is is very easy to slap together a prototype and get something practically unmaintainable out the door. Sadly, I see it happen far too often where a project goes out before it is ready. If you want some good examples take a look at some of the early access games on steam.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
I have been under the strong belief over the last 10 years or so that any demanding project which isn't making use of multiple threads is just not being designed well. I do see the value of simplicity in writing a single-threaded application, but I also know it isn't hard to multi-thread an application if you go with an event or task-based approach. (It isn't coincidence we are seeing task-based features being added to our current modern languages like C#, C++, JavaScript, etc). One advantage of being event-based is the ability to easily scale the application. Like everything, it does come with a cost, in particular it makes tracing the flow of logic a bit more complicated and reasoning about the system is slightly more challenging. However, it forces you to make clean separations of concerns and have an extremely low-coupling. I'm not a huge fan of actor-based systems, but the general idea behind actors I really like and make use of them. Below is an example of why I like this approach.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIXaMD2tiTEI43_JqQBt_6_mdetUJscGsQ-fLzbDxZMkjbVg4eUCHt1Tk4hjePR43UR7p4RsT6-bvazurh4Jp1GI74S5AsDNdFgLHSEbPVqmx01MxSuA1k_8wrqJFvlL4fo43ScVRX3LL5/s1600/Capture.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIXaMD2tiTEI43_JqQBt_6_mdetUJscGsQ-fLzbDxZMkjbVg4eUCHt1Tk4hjePR43UR7p4RsT6-bvazurh4Jp1GI74S5AsDNdFgLHSEbPVqmx01MxSuA1k_8wrqJFvlL4fo43ScVRX3LL5/s400/Capture.PNG" width="400" /></a></div>
In the above image you can see CPU activity of my computer when running the project I am working on under a moderate artificial work-load. Now I say artificial because I am still in the process of connecting everything together. Okay, that is a little bit of a lie, it is all connected I have just been cleaning up my communication layers between different areas of the project. Nevertheless, the above image is an example of an application which will scale with processing power. Moreover, half of the above load would vanish if I added a second computer. With my given architecture it is possible for me to have the application run on a server cluster without a huge investment of my time. I am not planning for it, but the option is there if I ever see the need to spend my time expanding the system. The reason I can do this is because I have designed the architecture of the system to operate this way.<br />
<br />
Again, if I just wanted to get a working prototype done and out the door that could have easily happened over a month ago. In fact I did have a basic working prototype in Unreal 4 a while ago. However, my concerns with Unreal's architecture made me decide on going with a hybrid approach where I am using Unreal 4 without building most of the project inside of it. In the next few weeks I will be able to start focusing on fleshing out the project instead of getting all the parts working together. Essentially, I'm on the edge of getting into the fun part of the project, but until then the shroud of mystery about the project will remain.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-82191344189303443372016-05-15T21:55:00.000-06:002016-05-15T21:55:31.442-06:00An interesting startNow I did say a biweekly schedule for updates here, but I've been focusing pretty heavily on the project that I didn't really want to pass last week just to post a new update.<br />
<br />
I think I am starting to feel the burn out of working on my project plus working full time. The last time I really felt this way was when I was working on Combatics Evolution. I really enjoyed that time even though it was extremely exhausting. I had a minor setback earlier this week when one of my drives that happens to house a large portion of the project decided to start dying on me. Luckily I've moved my data onto a new drive and created some online backups to keep my mind at ease. However, it still cost me about two days and a late night to get things set up again. I will be looking into getting a proper mirrored raid setup for my system in the near future but it isn't a pressing concern.<br />
<br />
Unfortunately, a lot of my time over the last 3 weeks has been all about prototyping and proving architectural decisions. Something I was successfully able to finish last week and very happy to report that each component of the system I am building will work together nicely. Now, I am still going to intentionally not talk about exactly what I am working on, but I will talk about a few of the things I was prototyping and a bit of the logic behind it.<br />
<br />
I'm going to be using Unreal 4 as my graphics engine. Notice I said graphics engine and not game engine. Part of my decision behind this was I really want to make use of the power of Unreal 4 when it comes to rendering and handling user input. I continued to spend a good amount of time digging into some of the internals of it as I started figuring out how I wanted to do the user interface. Unreal 4's GUI system is terrible, just terrible and poorly documented. I tend to find most of Unreal 4 is poorly documented and it is usually easier to look at the source code than to ask Google or read the documentation. This is one of the big downsides of Unreal 4, there is a lack of community and as a result a lack of good documentation and tutorials. Most of the tutorials I find tend to be all about blueprints... which is basically next to useless for me as I don't see the value in putting complex logic into a graphical based programming language. I think Unreal 4 was really targeted at non-developers and thus most of the guides and help talk about blueprints. Very few guides exist for 'how do I do X in C++' which has really made working with Unreal 4 a painfully slow grinding experience. I do see how once I become more fluent with the engine and gain knowledge about how I should be using it things will become noticeably better. The downside is that every hour I spend trying to figure out how to do something is an hour I am not actually doing something.<br />
<br />
The result of this is a painful development experience, and don't get me even started at how rough the experience is using C++ in Visual Studio. It reminds me of when I was working at Autodesk and about half the time I was waiting on a compiler and loading of binaries to just run a quick check of the application. My development style is very closely tied to a rapid PDCA cycle, which means anything that slows down the cycle, also slows down how I develop code. From my experience, most people who code follow a similar pattern where you develop the code in pieces over time instead of trying to write a large chunk of code without testing it. This is why I'm intending to only use Unreal 4 as a graphics engine. I want to harness the power of the engine but I don't want to be slowed down by the lack of documentation and the architecture of the engine which is inappropriate for my project. If I really wanted to stick with using Unreal 4 for the entire project then I would end up having to fight the engine at every turn to make it do what I need it to do. I don't want to fight it, I just want to use it.<br />
<br />
So how do I plan to escape the engine, and won't that be a lot more work? Well, yes, it will be a lot more work upfront as I need to come up with the complete system and I will need to clearly define communication interfaces between the Unreal engine and the rest of the system. This isn't a knee jerk reaction, I've been planning this and prototyping some aspects of the for the last 2 months. Recently (about 5 weeks ago) I decided to take a nose dive into Unreal and see what the engine had to offer. Basically evaluate how it works, what it can provide me, and build a basic prototype of the project I am planning to create in the end. My conclusion was I want to use the engine only as a graphics engine and interface for the user. Everything else I plan to make use of other frameworks and libraries in a modular architecture. Essentially, the way I am architecting the system will allow me to completely drop Unreal and replace it with something else, such as Unity. I won't do that unless the need arises, but it will always be an option.<br />
<br />
I am now at a point where all the technologies and components are tested and most of the non-trivial ones I have worked out how to integrate them together. I plan to make use of a large number of libraries and avoid writing code that isn't directly related to the project or connecting the libraries together. My current task is getting the full stack networking up and running, and perform some real-world testing of it to make sure the whole architecture is sound and practical. Once that task is complete and I then need to finish work on getting a reasonable way to get automated testing for it all working. I will also likely spend a small amount of time getting the basics of a build system together that will package everything nicely together. Once that is all complete, then I can start looking into actually building the project. I know I will need to brush up on my Blender knowledge in the next few weeks, but I'm going to defer that for as long as possible because I really would like to get the project going forward and out of the prototyping stage. Once I'm out of my initial prototyping stage and have the full stack functional I will start to talk about the details of the project, but until then I will continue to keep it light on the details.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-16406352583879240102016-04-24T21:39:00.000-06:002016-04-24T21:39:03.488-06:00Now where was I...It would appear that things haven't changed around here in a while. I'm going to shake it up a bit.<br />
<br />
When I last posted I was in graduate studies with very little spare time, and when I had spare time it really was to just try and relax and have some fun. It has been almost a year since I finished off my master's degree. In that time I've been doing what I feel like catching up on things I missed while in school.<br />
<br />
One thing I have been doing a lot more since I graduated was work on my hobby projects. I sort of decided around December that I wanted to get back to working on things and spend less time playing games. Before that point I had poked a few things here and there kept myself a bit familiar with things going on such as the arrival of a free version of the Unreal 4 engine. Updates with Libgdx and news about what to expect with Java 9.<br />
<br />
I've been working full time and with it a very heavy web development role which has brought my web skills back to the modern age and I've come to learn a lot more PHP, Javascript and SQL than I ever knew before. It was nice to get really sharp with my web skills as going forward it will be helpful if I ever need to crack out a website or dig into a database engine as a storage mechanism. It is sort of strange that before a year ago I never really valued the power of a database as most of the things I do with games has really been, keep it fast, keep it in memory and make it run well with multiple threads. When it comes to databases, you sort of get all that for free(ish) plus networking, data storage, persistence, redundancy if you scale it with multiple systems, etc.<br />
<br />
I have also come to understand different types of database systems. SQL vs no-SQL, Graphing, and Geospatial. Which has lead me to start thinking about how I could turn them into powerful back-ends for games. Maybe not what you typically think of when it comes to games, but I really feel they would be of use.<br />
<br />
There also has been two 'recent' languages that have caught my attention: Kotlin and Rust. Kotlin, I feel very much at home in because of my very extensive experience in the JVM ecosystem. Rust I haven't found the time to dig into but it is on my list of things to try out. I have a suspicion it will be a very pleasant low-level language. Another language I poked at a bit during my graduate studies what D. Which I have to say is a decent language if you come from a C++ background as it sort of melds together C++ and C#.<br />
<br />
I have gotten myself very familiar with Kotlin and been using it for a couple of projects I got on the go right now. One of them was a survival-based tower defense (think of a more complicated version of Plants vs Zombies). Which I developed to an almost playable state but then decided to drop the project for something else that I've been itching to work on. Using Kotlin I realized I have finally found a language which I really like working with. While I have used Java for years, part of me really hated the verboseness of it and I started playing around with Scala, Groovy, and Xtend. Each of which are decent but none of them I was satisfied with their tool or library support. In my opinion the quality of tools and libraries for a language outweighs everything else about a language. Kotlin sort of fixes that issue. Not only is it a non-verbose version of Java but it is very tightly integrated with Java such that making use of Java libraries is natural and straight forward. Xtend was very much the same way, but the tool support was fairly buggy and the syntax seemed more hacked together than well thought out.<br />
<br />
Anyways, I mentioned I have a new project I am working on... but for now I'm not going to say too much about it. It really has to do with the fact I am prototyping it out right now just to see if the tools I want to use will play nicely together. So far it has been good and I've been making progress but I feel its far too early to go into the details of what I am working on. Which goes back to my first point about shaking things up. Someone I know mentioned I hadn't updated my blog in a while... and it isn't because I haven't been up to much... more the opposite really. Now that things are sort of settled down in my life and things are a lot more stable I feel like updating this blog more often would be useful. I'm thinking to try and stick to a biweekly schedule... But I'm sure even with my best intentions I'll miss the odd week here or there.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com1tag:blogger.com,1999:blog-5958193840511042229.post-86420936135845620542014-09-26T15:32:00.000-06:002014-09-26T15:33:21.376-06:00Radio Silence is Bad!It has been a very busy time for me. I am a graduate student so spare time isn't always available. However, I can't really call it a good excuse for not posting on the blog for such a long time.<br />
<br />
I've been playing around with Unity 4.6 and have to say Unity is an outstanding engine in terms of ease of development. Especially with the UI framework coming with 4.6. However, on the surface and playing with the tutorials, it really makes me feel like its a tool designed for non-programmers. It does provide you with everything and a high-level abstraction for most concepts but it is really not designed for someone who has worked with low-level frameworks.<br />
<br />
LibGDX vs Unity. Naturally, after years of experience with LibGDX using Java, Scala, Groovy, and Xtend I have started to getting tired of having to write the same sort of code over and over to do relatively simple things. Yes, I can reuse most of the code, but after years you have to maintain it and update it to work with newer versions of both languages and libraries. In the end, it is usually best to rewrite it than spend the same amount of time fixing up your already existing code. However, this wastes my time as I spend it working on "engine code" instead of actually making a game. I have a model in the back of my head that every game needs to be written like its a fully networked game (even if it is singleplayer). This is because it forces you to think about your design and really makes it clear what the "game" needs to communicate with the "rendering" and "input" systems.<br />
<br />
As a singleplayer game, the "game", "rendering" and "input" systems are all wrapped up into a single unit because it is easy to do it that way. This is why when I see countless games first released as singleplayer I pretty much know they will almost never have high quality multiplayer and won't scale beyond a small group of people. I laugh at all the kickstarters, indiegogo, etc that list multiplayer as a stretch goal, because it tells me that they don't know what they are doing. They don't realize the hole they are digging themselves into and the amount of work it takes to dig yourself out of the pit.<br />
<br />
Developers like to do things the easy way, even if it means more work down the road. This isn't specific to games, this is all software, this is being human. This is why governments spend tons of money over the long run on multiple jobs sold to the lowest bidder when they are tendering projects. Everyone sees it as spend 100 and then another 100 later, instead of 150 now and 0 later. Obviously my numbers are made up, but its a very common theme. There is also the fear of spending 150 now is worse than spending 100 now for something nobody is going to use. Decision making is a very hard process, so I don't blame the government for all the poor decisions they make. Just because everyone does this does, it does not mean we have to do it. Just like everyone should be recycling because its a great way to preserve our resources, but it doesn't mean everyone will or even care about it.<br />
<br />
Unity so far seems to be a really good basis for the "rendering" and "input" part of the game. However, the whole component and script part is only good for a subset of games in general (obviously you could liberally apply it to every problem and it might do a decent job). Looking at 7 Days to Die, HearthStone, Timber and Stone, Race the Sun, and Kerbal Space Program which are all written in Unity and comparing them with Space Engineers, Prison Architect, Path of Exile, and Xenonauts which are all "in-house" engines sorta, you can really tell a difference in the games in terms of the number of bugs and development time. The Unity based games typically (note: not representative of all games) seem to get unbuggy features completed more quickly at the start of development. I really want to highlight 7 Days to Die against Space Engineers. The games are both approximately the same age and they both have: decent graphics, support multiplayer, voxel-based, and use C# as the main language. Space Engineers updates weekly, and 7 Days to Die is about monthly. I believe Space Engineers has a larger development team at least it sounds that way from what I have seen. 7 Days to Die's multiplayer is significantly more stable, supports 'infinite' generated landscapes, has pseudo-objectives, has a form of AI, is really a survival-based game. Space Engineers has pseudo-survival, it has some interesting automation mechanics, but lacks large world support, no gameplay-based objectives, and no gameplay-based AI. Both games offer a form of modding support and both would be considered sandbox games.<br />
<br />
From a software development perspective, I would easily rate 7 Days to Die higher, but both are certainly well made early access games. What has got my attention is how 7 Days to Die is done by a smaller group of people, seems to offer more features, and overall has less bugs (but still has bugs). The only real difference between the two is one is written on an "in-house" engine using SharpDX with Havok and the other is done in Unity. Let us not forget that Unturned (which is a relatively popular game for younger people) was written by a single 16 year old developer using Unity. If I compare Unturned to any of my earlier work, it hands down slaughters it in quality. This is using Java's 2D library, XNA with C#, MonoGame with C#, OpenGL with C++, DirectX with C++, and Android/Desktop games/apps with LibGDX. What is a common theme here? You can probably guess it Unity.<br />
<br />
After walking through a bunch of tutorials, I can easily see what is so attractive about Unity. Doing things in it is so mind-numbingly easy that even non-programmers could learn the basics and make a simple game with it. Advanced concepts are available right through the menus, and are typically done well enough they can be used right out of the box in the above games I mentioned. More importantly, the things that don't work out of box can be modified to make them work reasonably well for games. Certainly, good quality code, low-level logic and a whole other set of things seem to be lacking in most Unity games. However, they work, they sell, and more importantly they make money.<br />
<br />
One thing I haven't poked around with yet is the quality of networking libraries for Unity/C#. Java has extremely good libraries for this which work automatically across platforms (Win, OSX, Linux, RoboVM, Android) and architectures (ARM, x86) almost seamlessly with the exact same code and binaries (sorta binaries). It does appear on the surface that not using Unity puts small developers, hobbyists, and single developers at a huge disadvantage. There isn't much else on the market which is as mature and able to easily support tons of platforms (read as multi-platform == more money). Yes there are other game engines which can produce much more stunning looking games. However, "stunning looking games" == "has lots of artists" == "Not a small developer" which really means it would be stupid (yes I am going to just outright state it as it is) for a small group or individual to bother trying to make a game using those engines. The biggest hurdle for developing games is finishing the project. The best way to finish a project is to make everything as easy as possible and take as little time as possible. I really believe Unity can help me with that aspect.<br />
<br />
So where is this long giant blob of text leading me?<br />
<br />
I have a potential game idea I want to explore, it is related to other projects I have worked on (many not ever released to public), and I really think using Unity might actually allow it to come to life much faster than if I was trying to do it in other engines/libraries. Of course, jumping immediately onto this larger project without really getting personal with Unity is a recipe for disaster. Therefore, I will likely be working on a much smaller and simpler game first to make sure I understand the bells and whistles of Unity.<br />
<br />
Last but not least, a minor side note: C# > Java. This is coming from someone with 10+ years of Java experience. My reason for not using C# more often, sooner was trying to find a way to easily develop mobile/desktop games without wanting to bash my head in from lack of high-quality tool support and libraries. Fortunately, in the last 4ish years C# has grown massively and it's widely accepted as a good language to use. This means going forward I will likely stick with it for my main development. Of course, Java and Python offer other advantages as well so they will be kept around for their nice features. Now if type annotations make there way into Python 3.5 I will think Python is the best scripting language ever! Okay Perl, Ruby, Javascript, Dart, Lua, and Coffeescript are nice but I still prefer the syntax for Python. Besides, I can mix and match as well. I would also really like D to become more popular because it just makes C++ look silly, but D has pretty much been out of the spotlight for so long I doubt it will gain traction any time soon, at least not like C#.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-40785372573389601362014-05-20T18:57:00.002-06:002014-05-20T18:57:50.388-06:00Windows 8.1 Round 2Many months ago in the summer of 2013 Microsoft released version of Windows 8.1 for people to test out. I blindly went ahead and installed it... which was the biggest waste of 3 days I've done in a long time. Not only did it prove to be insanely unstable, but many applications I needed simply couldn't function on Windows 8.1. It wasn't fully ready for release and was more of a showcase anyways so I basically blew it off as pre-release defects.<div>
<br /></div>
<div>
I decided after all this time to upgrade to 8.1, in May 2014, over half a year since it has been released. My upgrade process went as follows:</div>
<div>
<ol>
<li>Download upgrade to 8.1 from store I never use</li>
<li>Install upgrade to 8.1 which was fairly quick in terms of OS upgrades</li>
<li>Watch computer reboot and do 'magic'</li>
<li>Watch Windows 8.1 start up</li>
<li>Watch Windows 8.1 give me a blue screen and reboot</li>
<li>Watch Windows 8.1 downgrade itself back to Windows 8 and reboot</li>
<li>Windows 8 loads up and kindly informs me the upgrade failed and I am now running Windows 8</li>
</ol>
<div>
I don't really have an exotic hardware setup, yes I run high-end parts but nothing strange and a modest overclock compared to most. But after this long I would have thought Microsoft would have invested the time to work out the upgrade bugs... Instead I find a nice thread back from October 17, 2013 with 400+ responses talking about how the upgrade fails in an identical manner to me.</div>
</div>
<div>
<br /></div>
<div>
Windows 8 keeps looking more and more like a lemon, good thing it boots fast or I would have downgraded (or should I say upgrade) to 7 a long time ago...</div>
<div>
<br /></div>
<div>
Will Windows 9 prove to be awesome? Only time and Microsoft can tell you that... Some days I wish Linux had better game support.</div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-69011431784822997312014-05-09T12:46:00.000-06:002014-06-13T04:19:41.095-06:00Bare-bones EclipseI work with many languages, but I like to work with Java. I would prefer to work with C# if the tool/library support was as good as Java, but unfortunately it isn't.<br />
<br />
Eclipse and IntelliJ are the 'best' IDEs to use (in 2014) when working with Java. Gradle is the most promising build system for Java. However, Eclipse's default installation you find when searching for it on Google points to a bloated version which has a bunch of unneeded junk. Most of it will simply slow down the IDE. This is why I have been using the Platform Runtime Binary and then adding only the components I need. You can find it from the download site at:<br />
<br />
<a href="http://download.eclipse.org/eclipse/downloads/index.html">http://download.eclipse.org/eclipse/downloads/index.html</a><br />
<br />
Just follow to the version you want, scroll down until you find the Platform Runtime Binary group and select the version for your OS. When you first launch Eclipse it will load fairly fast, but it will also support absolutely nothing except general projects. I also suggest making a copy of this eclipse installation and using a copy for each language you wish to work with. For example, one version per language or set of languages you are going to use on projects. This keeps Eclipse running extremely fast and means you only ever load the plugins which are absolutely required for your project. There might be a way to disable (without uninstalling) plugins but I have not found the option anywhere. Also some poorly maintained plugins may not cleanly uninstall themselves and cause issues over time which are a nightmare to track down. <br />
<br />Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-83788942169398534612014-05-06T10:47:00.000-06:002014-05-06T10:47:03.198-06:00A "Small" List of Useful Tools and KnowledgeAnyone who has shared files has probably heard of <a href="https://www.dropbox.com/" target="_blank">Dropbox</a>. Though it is only one service of many file sharing services. I would never argue it is the best, but it does offer some pretty decent basic services if you want to store a backup copy of files onto the magical thing called "The Cloud". For free, you get limited space (a few GB), window's shell integration, client-side syncing, and ability to create public direct links to your files. I haven't ever had an issue or a complaint about it other than the brutally limited space (if you want to sync all your files you are out of luck or going to pay a fortune with Dropbox).<br />
<br />
<a href="https://drive.google.com/%E2%80%8E" target="_blank">Google Drive</a>, also provides a limited way of sharing files. It isn't ideal for syncing data and also suffers from limited free space. However, if you use google documents then you technically have unlimited space as they don't count. Not to mention the fact you can work with nearly limitless number of people on the same document together is a great bonus. After using it since... 2009? I have seen it slowly evolve into a great tool for collaboration, and best of all it is free. Need a notepad to share notes with yourself between computers or others, it works like a charm and provides you with a great backup location accessible from anywhere.<br />
<br />
<a href="http://www.bittorrent.com/sync" target="_blank">BitTorrent Sync</a>, is my absolute favourite tool. It is still in beta (but I've used/built enough software to think everything is always in beta) and works very well between computers. Think of it as a torrent which you can add/update/remove files, encrypt, password protect and runs in the background without a second thought. The idea of using P2P for backing up and sharing data between my devices is absolutely awesome. The best part is that the files are stored locally, so I don't need to spend a fortune for space in "The Cloud". I have 3 computers (server, desktop, laptop) so keeping my data synced between them is required.<br />
<br />
<a href="http://www.7-zip.org/%E2%80%8E" target="_blank">7zip</a>, is an absolute must have for compression. Winrar is like the poor sibling in comparison to what 7zip offers. The fact I can choose which compression method, the compression level, encryption, partitioning, etc in a very simple manner means any data I rarely access I can compress down and then put it on my sync folder to provide a compact backup of my data. If it isn't compressible, I can grab the folder with the files and throw it in my sync directories.<br />
<br />
<a href="http://mirillis.com/en/products/action.html" target="_blank">Action!</a>, meets the need high-performance and easy to use capturing software. You can separately record multiple channels with <a href="http://audacity.sourceforge.net/" target="_blank">Audacity</a> and edit your audio with minimal effort. These two together is enough to record content like professionals and it only costs you $40. Not to mention both are extremely efficient at recording so you don't have to worry about large performance drops while recording. A common issue with FRAPS. The runner up is <a href="http://exkode.com/dxtory-features-en.html" target="_blank">Dxtory,</a> which provides you with everything you want. I prefer Action! but both are excellent.<br />
<br />
<a href="https://www.piriform.com/ccleaner" target="_blank">CCleaner</a>, is your best friend if you are a Windows user. This little tool is like a weight-loss magic pill for Windows. Keeps the registry clean (a bit aggressively) and removes temp files which really are not worth keeping around. It also allows you to deeply purge files if you want to clear caches, stored passwords, etc. Another important thing is making sure your PATH is good and not full of crap. I suggest <a href="http://www.softpedia.com/get/System/System-Miscellaneous/Path-Editor.shtml" target="_blank">Path Editor</a>, but there are many other tools like it. This one just has a bunch of good simple and easy to use features.<br />
<br />
<a href="http://www.piriform.com/speccy" target="_blank">Speccy</a>, is great if you don't have the specs of all your computers memorized to extreme detail. It is probably the least important program mentioned here, but when you want to know all the details of your hardware (and some software) it is great for telling you what is inside without opening the box.<br />
<br />
<a href="http://www.memtest.org/" target="_blank">Memtest86+</a>, is most likely the best memory testing tool out there. If you want to diagnose a memory issue this is your go to solution. <a href="http://www.mersenne.org/download/index.php" target="_blank">Prime95</a>, is a great CPU/Memory stress tester as it allows you to focus on what parts you are wanting to stress. This is important for finding stable overclocks and just general CPU benchmarking (but mostly just for stable OC, I would never consider a single bench as a good indicator of performance). <a href="http://www.ozone3d.net/benchmarks/fur/" target="_blank">FurMark</a>, GPU stress/benchmark tool. This tool will let you know if your GPU is being cooled properly as it will stress it to the absolute maximum. This is beyond anything you will ever encounter while gaming or almost any other activity. Great for testing stable GPU OC and system heat management. Finally, <a href="http://speedtest.net/">Speedtest.net</a>, for checking your network connection quality as slow internet is the greatest source of frustration for anyone.<br />
<br />
Operating system is by far the most important software for any computer. The thing is, I have no favourite; however, I do use Windows the most. I use OS X the least, mostly because I don't own a Mac and don't see it providing me with an advantage over anything else. I actually suggest Macs to many people simply because of the "easy to use" part of it, but usually I suggest people simply stick to what they are already used to. I.e. I don't tell a Windows user to use a Mac or a Mac user to use a Windows machine, because most people don't want to spend the time learning all the 'tricks' with a new OS. I have never suggested any Linux distribution to any non-technical users as most of the common software will not be available for them (WINE, cough... yes but is that worth teaching them a whole new environment?). The last thing I want is to teach/explain to them the alternatives and how to use a different OS. If I were to suggest a Linux distribution to a user, it would be either Mint or Ubuntu. Server would be CentOS, but that is mostly because of my familiarity with it. Anyone who games, I would suggest Windows without a second thought. For any developer, I would say you should know all of them, pick your favourite and be using VMs or multi-boot for the others. In this day and age, a developer should know all the popular OSes (Windows, OS X, Linux), including the mobile ones (Android and iOS).<br />
<br />
A developer should know most of the popular programming languages and be able to make an application in any of them: C/C++, C#, Java, Python, JS/HTML5 and Php. It wouldn't hurt to also be knowledgeable about Ruby, Lua, Scala, Haskell, D, Obj-C, Shell and Perl. Of course, there are many others to list but really by having the above you would know a majority of different programming paradigms and styles. If you only know 1-3 languages and only use those for everything then there is absolutely no way you can consider yourself a good programmer. Yes, you should have 1-3 languages you are an 'expert' in, but knowing more languages means you better understand how to decompose problems into there obvious solutions. It also means you understand there is no silver bullet language which is the best for everything. A concept most developers seem to naively do without realizing it.<br />
<br />
I could easily just keep going with this, maybe I'll do a part 2 in the future and talk about media players, anti-virus, browser, IDEs, text editors, mail clients, etc... I guess I never realized until now just how many applications and tools I use for various tasks. By no means is anything I mention the best, it is just currently the ones I like the most. Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com1tag:blogger.com,1999:blog-5958193840511042229.post-8469527081853715302014-02-17T19:59:00.002-07:002014-02-17T19:59:22.922-07:00Libgdx 3D ParticlesI recently found out about libgdx getting 3D particle support as well as dropping Android 1.5 support. First of all, Android 1.5 is a very limited version of Android so the idea of removing the dependency and moving to OpenGL ES 2.0 as the minimum should prove to be good for the library. The recent addition of 3D particles is pretty exciting as it will allow me to play around with it and get a feeling for it. However, I've been extremely busy and have no time for hobby related programming because of the demands other parts of my life are making. That just means I have something to look forward to playing with in the future :).Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-18178171327463398852014-02-04T19:53:00.001-07:002014-02-04T19:53:48.049-07:00XtendIt has been a while, but it is time for another post.<br />
<br />
After my love/hate relationship with Scala went to a sour end I continued to work with Java and for the most part have quiet enjoyed working with tools and libraries which not only work as expected but pretty much always work as intended. Recently, I have been working on a compiler for a subset of Java as part of a project. It has been very interesting to see how its all done and even learning about compiler compilers and how to do the various types of parsing (LL(1), LR(0), SLR(1), LALR(1), etc...). All of a sudden in the middle of all this I had a brilliant idea, why don't I make a simple little compiler that takes some of the simple key features from Scala I like and make a language extension to Java!<br />
<br />
No need for the more exotic features of Scala, a brand new exotic runtime library, or byte code generation. I would simply emit Java source files and not have to write as much boilerplate code! Some basic type inference using var/val, make default visibility public (because who really has a real-world use case for package private), I could also create extension methods (because they are totally awesome), add properties to Java or operators/overloading, etc. Like all the features Java *should* have but doesn't. My thinking is along the lines of the fact things like Coffeescript and Typescript exist for Javascript. Java can compile down to Javascript for the most part (GWT). Additionally, if I make it compile down to Java 5/6 it will then work with Android without any compatibility issues.<br />
<br />
However, I decided maybe it would be easier if this was done with some light-weight macro system which would run before the Java compiler. I'm not talking about C-style pre-processor here, I'm talking about a type-aware first-class citizen macroing system that we use in the 21st century. I decided it was time to do some quick searching because there is no way I am the first or only person to think about this (how to get rid of all the boilerplate from Java). So after a few searches and a bunch of people on Stackoverflow explaining why macros are bad something popped up called Xtend.<br />
<br />
What is Xtend? Well, the name is pretty much what you think it means. It is an extension for Java that is not meant to be a full-blown language replacement but something which compiles down to Java source and is then compiled as Java code. It doesn't try to do any of the other fancy stuff you find in other JVM languages, because the goal is to make it 100% interoperable with Java. It has the exact same type system as Java and provides pretty much every feature I mentioned above, PLUS more. Additionally, it is designed to work well with Java 8's new API meaning I won't have to worry about future compatibility. It also creates Java 5 compatible files which means Android compatible out of box. It does have its own library, but unlike the other JVM languages it is a lightweight wrapper to simply provide syntactic sugar instead of new classes/structures/etc. Why is this good? Well, I get to continue to use everything I know without having to worry about cross-language library annoyances.<br />
<br />
The best part so far is the version 2.5.1 has top-notch Eclipse integration, it works as described and no surprises. Mind you they really need to make it easier to create Xtend files by right-clicking on a project (maybe some Xtend perspective?!?!). The lambda structure feels a bit funky as I haven't seen anything like it before. Then again, Clojure also has a slightly odd style but it isn't too strange. Method dispatch and guards are very handy (think Scala's match construct). Everything has a return value, which is very Scala-like. It has value classes, just like Scala's case classes. It removes the default fall through behavior of switch statements (which is honestly the worst and most pointless legacy thing in any modern programming language). I could just list the features it offers but that would continue to make this post more massive. The really nice part is the compiler hooks, and allowing people to easily extend Xtend. I'm almost tempted to say some of the Java 6 concurrency API should be integrated more tightly as a future feature of Xtend, but for the time being I'm glad to have found a wonderful tool which provides the exact solution I've been search for! The other thing I might start looking at is Xtext; however, that appears to fall more into the DSL territory I refuse to dirty my hands in.<br />
<br />
Seriously though, why haven't I found this sooner!?Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-1236065898558536452013-12-14T22:40:00.000-07:002013-12-29T00:07:08.171-07:00Libgdx 3D APIThe 3D API for Libgdx is hardly a new thing as it has been around for many months. I initially peeked at it back around when it was first proposed and the initial implementation. The work they have done with it is absolutely awesome, but the framework is still missing some key aspects. Xoppa did a wonderful tutorial on the various aspects of the API and introduced a bunch of the main concepts <a href="http://blog.xoppa.com/basic-3d-using-libgdx-2/" target="_blank">here</a>. Those who are familiar with OpenGL and 3D rendering in general will probably be able to quickly skim over most of it and look at a few examples without much trouble.<br />
<br />
It certainly matches what it was originally intended to do by mimicking the design of the Scene2d API. It also provides a great number of utilities to help with working in 3D. I have minimal knowledge of creating 3D models, but I do know how to work with already existing models so most of it isn't that new for me. There seems to be a pretty common theme, if I want to do anything in 3D for games as an indie I better start learning 3D modeling programs (i.e. Blender). There isn't anything officially included which deals with shadows (but there is an experimental directional shadow light which uses shadow mapping). Being experimental is kind of lame because I want to use it and most of what is inside it does not look experimental to me. In fact, it matches pretty much what I have done in past test projects with shadows.<br />
<br />
No 3D particle system is really going to put a huge damper things because it is a very important aspect to any modern 3D game. Particle effects is almost as fundamental as sound effects, but it looks like I will have to roll my own solution if I want to have such a system in a game. I could always do things with bullet, but sometimes I just want something simple like smoke which doesn't need to be modeled accurately, but just provide a visual for people. Minus the whole missing features which feel essential, the 3D API is very easy to work with and looks fairly expandable. Hopefully a few more 'nice' features are added to support the previously mentioned parts, but overall I am satisfied with it.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-12437681373508764912013-12-08T20:07:00.000-07:002013-12-08T20:07:09.126-07:00No More ScalaMy love/hate relationship with Scala is finally coming to an end. I am ditching the language entirely not because I don't like the language, but the biggest issue is tool support and well... the lack of it.<br />
<br />
<b>Using Scala has slowed down my development time because nothing works as well as it does when working in Java.</b><br />
<br />
When it comes to cross-platform development you need to make sure everything you are working with will behave as expected and without causing you more complications or headaches. This is very important for people who are working on very small teams and can't afford to be spending time diagnosing issues. Scala does work well when you think of development speed in terms of how many characters it takes to do a task. However, that is a very biased view of development and almost backwards way to develop. This isn't the early 80s where programs are only written using a basic text editor and some syntax highlighting. It is expected to have a full IDE providing you with everything you would want and more. Scala has IDE support, but all the ones I have worked with seem to be missing the key features I use all the time in Java. It just feels so backwards and slow to not have an intelligent code completion/assist. Or be missing auto-generation of common code snippets with context awareness. Then having the tools you rely on break or fail to work on occasion for no good reason other than you've been using it for too long in one sitting.<br />
<br />
The part the drives me nuts with Scala is trying to use it for game development. It offers a huge potential for providing many features to speed up development, but trying to make it work flawlessly/efficiently with Android has only caused more issues than solutions. I am using Java libraries because the lack of good libraries for Scala is frustrating and even the standard library for Scala is written with poor documentation and strictly from the functional point of view (not that their is anything wrong with it, but not everyone knows functional languages inside out and be able to infer what symbols used by the DSL mean). Scala libraries are notorious for using specialized DSL for no good reason other than because the developers think/feel it makes it awesome. DSL means steeper learning curve for all developers trying to use the library. Additionally, it means when someone is trying to do something outside of the status quo, its impressively complicated to bend a DSL designed for a certain workflow to do something else. Libraries should be convenient, easy to use, and perform effectively at the tasks they are built for. Most of the popular (non-enterprise) Java libraries follow these key aspects; hence, are popular by many hobbyist/professional developers.<br />
<br />
I am strictly going to be using Java for game development from this point forward as I have not found anything I can develop 'code' in faster. When I say code I am not referring to lines of code, but am actually referring to features and functionality. One common complaint with Java is the verbosity of the code, and that is a very real issue. However, this is why I make extensive use of tools which automate tons of the boilerplate code. I can only hope Android will eventually support Java 8 because so many amazing features are coming just around the corner. It is ironic that iOS might support Java 8 before Android because of AOT native compilers... which actually makes me wonder if using such a compiler might allow me to make native applications for Android using Java 8. Oracle seems to be hinting at it... maybe the stars will align and I will get the best of all worlds.<br />
<br />
<br />Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com1tag:blogger.com,1999:blog-5958193840511042229.post-91491604865178902622013-11-23T15:14:00.001-07:002013-11-23T15:14:13.640-07:00Status UpdateIt has been a while since I last mentioned anything here. Naturally, that usually means it is a good time to write what I have been up to lately. I could always write more about what I have been doing recently (other than research/school work), but this post is getting excessively long.<div>
<br /></div>
<div>
I recently wrote an addon for the Minecraft Mod called TerraFirmaCraft. However, I am only really doing bugfixes and discussions related to it for the next while because there are two big things I'm concerned about. TerraFrimaCraft Build 78 and Minecraft 1.7.x update. Both of these are going to have significant changes to the addon, one will force me to rewrite any network code I have created. This is primarily why I won't be making any new content for the addon in the near future, as I know I'll have to redo a lot of it if I decide to tackle some more of the complicated things.</div>
<div>
<br /></div>
<div>
Minecon 2013 was a huge disappointment, no I didn't go but just watching some of the streams made me realize a few things about Minecraft. The community appears to be hugely based on youth and the developers really spoiled the whole event by having NOTHING exciting to talk about. It really was just a weekend about praising Minecraft and talking about random things most people aren't overly interested in. Okay, so they talked about twitch, but do we really need more people streaming Minecraft? It is kind of a saturated thing as it is... Then again with all the new consoles, streaming is apparently going mainstream (no pun intended). There are really only a handful of reasons to watch a stream... You want to see how someone skilled at the game plays (meaning the game really needs a skill factor). You want to watch a person/group of funny people play a game for entertainment. You want to see what mods/mechanics/achievements/other game features are like because you want to learn more about them. Beyond that, watching someone else's stream really doesn't provide a whole lot of value. By allowing a lower barrier of entry to streaming content really adds no benefit and will probably bloat streaming services with a ton of streamers nobody really wants/is going to watch.</div>
<div>
<br /></div>
<div>
Blizzcon 2013 in contrast to Minecon 2013 was absolutely amazing. Blizzard is obviously a much larger company, but they really understand how/why they should do a convention. They showed off <a href="http://us.battle.net/hearthstone/en/" target="_blank">Hearthstone</a> and <a href="http://www.heroesofthestorm.com/en-us" target="_blank">Heros of the Storm</a> very effectively which added a ton of hype about the games. I haven't really played many card games, but I do like how simply and complicated Hearthstone is, and will likely play it a bit when the game goes open beta. Heros of the Storm looks amazing from what is already shown. The issue I have about League of Legends is the grind in the game and it is too competitive. I like some competition, but I mostly play games to enjoy them and playing multiplayer over and over has never really appealed to me much. Hence why I only played Starcraft for the first couple weeks when it comes out and then sorta stop playing it. Diablo 3 expansion looks promising, feedback so far from the beta is fairly positive and considering they are actually allowing people to beta test the entire game means there shouldn't be that many surprises this time.</div>
<div>
<br /></div>
<div>
Side note, the types of games I really enjoy are turn-based with time constraints. Example, blitz chess, any turn-based game with a short turn timer. Why a short turn timer? Because it forces people to think quickly and plan only slightly into the future without giving them time to evaluate all possible moves. Additionally, it keeps the action flowing and makes the game interactive so I don't sit there for a couple minutes waiting on someone else to do something. I don't enjoy real time games very much because it boils down to reaction time in many cases (when you play skilled player vs skilled player). Obviously that is a gross simplification as some real time games can involve a ton of strategy as well. </div>
<div>
<br /></div>
<div>
Randomness makes games more interesting. This also means even if you know the 'best' way to do something, you could still lose. Some people hate that concept, but if you could predetermine what is the best way to play, why bother playing at all as you know walking into the game who will win. Randomness also evens out the disparity between really good and really bad moves. Sometimes the best move could result in a poor outcome but more often then not it will prove to be a good outcome. This means you shouldn't do the same thing every time and you need to adapt to the variables in play... it makes planning ahead less critical and being able to deal with the current situation more important. This is the reason why the current best backgammon bot only looks 2 turns ahead at most... Or why some of the best competitive bots in Tetris only look at the current piece and not what is in the queue (especially if the queue is shared between competitors).</div>
<div>
<br /></div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-35317080659730829542013-10-18T10:21:00.000-06:002013-10-18T10:21:07.571-06:00Java 8 Method Reference and Lambda PerformanceI happened to come across a <a href="http://stackoverflow.com/questions/14146570/calling-a-getter-in-java-though-reflection-whats-the-fastest-way-to-repeatedly" target="_blank">post on SO</a> talking about performance of methods called via reflection and method handles. I was under the impression that method handles was a Java 8 thing. To my surprise it is actually in Java 7 (I've been coding android for a while so never played much with it). I figure it would be worth while to extend the answers there to show off the performance of some of the Java 8 features. I.e. lambda and method references. It doesn't actually answer the question there so I won't pollute it on SO but I can write it here to show it:<br />
<br />
I took the basic code for the micro-benchmark (again micro, does not truly reflect real world performance). A quick dump of my laptop specs (cause people always ask):<br />
<br />
Operating System<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Windows 7 Ultimate 64-bit SP1<br />
CPU<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Intel Core i7 620M @ 2.67GHz<span class="Apple-tab-span" style="white-space: pre;"> </span>46 °C<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Arrandale 32nm Technology<br />
RAM<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>4.00GB Dual-Channel DDR3 @ 532MHz (7-7-7-20)<br />
Motherboard<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>LENOVO 2516CTO (None)<span class="Apple-tab-span" style="white-space: pre;"> </span>53 °C<br />
Graphics<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>ThinkPad Display 1440x900 (1440x900@60Hz)<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>DELL P2211H (1920x1080@60Hz)<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>256MB NVIDIA NVS 3100M (Lenovo)<br />
Hard Drives<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>298GB HITACHI HTS725032A9A364 ATA Device (SATA)<span class="Apple-tab-span" style="white-space: pre;"> </span>33 °C<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>SD Memory Card (NULL)<br />
Optical Drives<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Optiarc DVD RW AD-7930H ATA Device<br />
Audio<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Conexant 20585 SmartAudio HD<br />
<br />
The code I am running is pretty much copy paste from the SO post, but I added a few lines to add in the Java 8 stuff. Anyone familiar with Java will see the new syntax and be in awe at the performance.<br />
<br />
<script class="brush: java" type="syntaxhighlighter">
<![CDATA[
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.reflect.Method;
import java.math.BigDecimal;
public abstract class Bench {
final String name;
public Bench(String name) {
this.name = name;
}
abstract int run(int iterations) throws Throwable;
private BigDecimal time() {
try {
int nextI = 1;
int i;
long duration;
do {
i = nextI;
long start = System.nanoTime();
run(i);
duration = System.nanoTime() - start;
nextI = (i << 1) | 1;
} while (duration < 100000000 && nextI > 0);
return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
} catch (Throwable e) {
throw new RuntimeException(e);
}
}
@Override
public String toString() {
return name + "\t" + time() + " ns";
}
static class C {
public Integer foo() {
return 1;
}
}
static final MethodHandle sfmh;
static {
try {
Method m = C.class.getMethod("foo");
sfmh = MethodHandles.lookup().unreflect(m);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
static interface Foo {
Integer foo();
}
public static void main(String[] args) throws Exception {
final C invocationTarget = new C();
final Method m = C.class.getMethod("foo");
final Method am = C.class.getMethod("foo");
am.setAccessible(true);
final MethodHandle mh = sfmh;
Foo methodRef = invocationTarget::foo;
Foo methodLambda = () -> { return 1; };
Bench[] marks = {
new Bench("reflective invocation (without setAccessible)") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += (Integer) m.invoke(invocationTarget);
}
return x;
}
}, new Bench("reflective invocation (with setAccessible)") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += (Integer) am.invoke(invocationTarget);
}
return x;
}
}, new Bench("methodhandle invocation") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += (Integer) mh.invokeExact(invocationTarget);
}
return x;
}
}, new Bench("static final methodhandle invocation") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += (Integer) sfmh.invokeExact(invocationTarget);
}
return x;
}
}, new Bench("direct invocation") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += invocationTarget.foo();
}
return x;
}
}, new Bench("method reference invocation") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += methodRef.foo();
}
return x;
}
}, new Bench("lambda invocation") {
@Override
int run(int iterations) throws Throwable {
int x = 0;
for (int i = 0; i < iterations; i++) {
x += methodLambda.foo();
}
return x;
}
}};
for (Bench bm : marks) {
System.out.println(bm);
}
}
}
]]></script>
<br />
And of course here are the results:<br />
<br />
reflective invocation (without setAccessible)<span class="Apple-tab-span" style="white-space: pre;"> </span>4.847 ns<br />
reflective invocation (with setAccessible)<span class="Apple-tab-span" style="white-space: pre;"> </span>4.593 ns<br />
methodhandle invocation<span class="Apple-tab-span" style="white-space: pre;"> </span>11.511 ns<br />
static final methodhandle invocation<span class="Apple-tab-span" style="white-space: pre;"> </span>0.000 ns<br />
direct invocation<span class="Apple-tab-span" style="white-space: pre;"> </span>0.000 ns<br />
method reference invocation<span class="Apple-tab-span" style="white-space: pre;"> </span>0.000 ns<br />
lambda invocation<span class="Apple-tab-span" style="white-space: pre;"> </span>0.000 ns<br />
<div>
<br /></div>
<div>
Which pretty much means the performance is no better than static final methodhandles OR direct invocations... which goes to show how huge of an impact these new constructs will have to functional programming in Java. I am impressed.</div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com2tag:blogger.com,1999:blog-5958193840511042229.post-22034538155806578662013-10-15T13:02:00.000-06:002013-10-15T13:02:26.833-06:00TerraFirmaCraft and Minecraft ForgeI recently came across a wonder mod called <a href="http://terrafirmacraft.com/index.html" target="_blank">TerraFirmaCraft </a>which has proven to be a fairly amazing rework of survival Minecraft. It adds a huge depth to the game play, and unlike every version of Minecraft since early alpha when I first started to play it actually makes the game harder and removes all the 'mob farming/automation' from the game. I find it pretty amazing because a lot of the new red-stone stuff is 'neat' but it really just makes the easy parts of the game even easier. I wouldn't be able to describe all the changes it has done to the game in a single post (well at least one that people would read) so instead I will simply put it this way: Everything takes more effort, nothing is automated, and you really have to actually work towards your goals. It means when you actually build your first house in TFC it feels like a huge accomplishment because you probably spent a few days trying to gather resources and fighting off significantly more powerful mobs.<br />
<br />
This mod has also reminded me of all the parts about Minecraft I really enjoy and how Minecraft Forge allows me to actually tackle some of my mod ideas without trying to dig through Minecraft source (yuck). Needless to say, TFC is still in a beta and has lots of areas to improve. On the other hand, it is very fun and I agree with the premise of the project. As a result, I have decided to contribute my time and effort towards the project to improve it and by writing a couple add-ons for the core mod. My first change has been to revive an older addon which is no longer being maintained called <a href="http://terrafirmacraft.com/f/topic/4803-16207721-terrabow-mod-v071/" target="_blank">TerraBow</a>. I will likely take the information about it and make an actual page here for people to view. I will also be making posts about other mods I write for TFC and make occasional progress reports (since doing that seems to both tell people I am making progress, and gives me something to refer to).Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-61008644282968179262013-09-26T09:44:00.002-06:002013-09-26T16:19:30.632-06:00Java 8 Developer PreviewI'm sure 99% of developers don't use the bleeding edge, but my curiosity got the best of me and I decided to see what does Java 8 really mean. The big thing about Java 8 is that it means less boilerplate code and performance increases without having to write much code at all.<br />
<br />
<i>Edit:</i><br />
<i><br /></i>
<i>If you would like to try out Java 8 w/ Eclipse for yourself, there is only two easy steps:</i><br />
<br />
<ul>
<li><i>You will need to download and install the JDK8 developer preview from <a href="https://jdk8.java.net/download.html" target="_blank">here</a>.</i></li>
<li><i>Get a bleeding edge Eclipse build from <a href="http://downloads.efxclipse.org/eclipse-java8/2013-09-13/" target="_blank">here</a>. (Note: this is a preview and likely will have a few glitches).</i></li>
</ul>
<br />
<br />
However, I don't get to have candy and eat it because Android doesn't support anything past Java 6. It is actually kinda depressing because a ton of things I like about Scala are being added into Java 8. Let's do a quick comparison of what has been added after Java 6 (this is by no means complete):<br />
<br />
Java 7<br />
<br />
<ul>
<li>Try-with-resources, basically the equal to 'using' blocks from C#. If you aren't familiar, think of them as automatically closing of resources/streams/etc.</li>
<li>String switch statements, before you were limited to integer types and enums. C# has had this one for a while and it also came with Java 7.</li>
<li>ForkJoinPool, a concurrency method to support load balanced parallelism by allowing thread pools to steal work from other busy threads.</li>
<li>ThreadLocalRandom, a random generator which is thread-safe!</li>
<li>New Java Path features, fixes up some major issues with Java and file systems (such as path normalization across platforms, symbolic links, etc).</li>
<li>Multiple catch statements, reducing the number of catch clauses.</li>
<li>Type inference on generics!</li>
</ul>
<div>
(A few things are missing from the above, but I really don't need to make this longer)</div>
<div>
<br /></div>
<div>
Java 8</div>
<div>
<ul>
<li>Lambda Expressions, basically a dynamic invoke of a method which uses type inference for the arguments and allows you to create closures with them. It really simplifies the language and removes the need for anonymous classes! </li>
<ul>
<li>Ex: Arrays.sort(x, (s1, s2) -> s1.charAt(0) - s2.charAt(0));</li>
<li>s1 and s2 are Strings (type inference), you sort them based on the value of the first char.</li>
</ul>
<li>Method References, create a lambda and pass it around like an object. Who wouldn't want that!</li>
<li>Default Methods, create stubs or default implementations in your interfaces. This is pretty huge as it basically allows Java to do some 'smart' multiple inheritance and allows you to write a single implementation common to multiple classes.</li>
<li>Streaming API, functional operators for collections (or even arrays) in Java. Think of it as LINQ for Java if you come from C#. It also performs lazy evaluation to make life even better.</li>
<li>Parallel Collections, want to make your sorting parallel? want to perform a bunch of actions on a collection in parallel? You can now do this via the streaming API to basically make your code parallel without actually writing anything special for it.</li>
<ul>
<li>myList.parallelStream().forEach((s) -> System.out.println(s)); // Parallel</li>
<li>myList.stream().forEach((s) -> System.out.println(s)); // Serial</li>
</ul>
<li>New JavaScript engine built-in which offers near V8 level of performance (from what I've heard).</li>
<li>Removed PermGen space from JVM (most people have no idea what this is). Basically means less configuration of the JVM when running applications.</li>
<li>A non-internal API for Base64 encode/decode (Long over due).</li>
<li>New Date & Time API, based on Joda Time!</li>
<li>Statically-Linked JNI Libraries!</li>
</ul>
<div>
(Again, a few things are missing from the above, but I really don't need to make this longer)</div>
</div>
<div>
<br /></div>
<div>
That list is pretty big when comparing it to Android's Java. I believe there are a few ways to get some of the Java 7 features working on Android, but I know almost everything in Java 8 is very likely to not work with Android. Scala 2.11 is targeting Java 6, in part because of Android, which means they will not be able to gain any significant performance improvements provided by the latest version of Java. I would expect 2.12 will be targeting Java 8 and hopefully so will Android by that time.</div>
<div>
<br /></div>
<div>
What I hope is in Java 9:</div>
<div>
<ul>
<li>Full type inference! I really would love to seem something like var/val from Scala or even just var from C#. It is pretty clear not all types need to be visibly shown for all variables and the compiler can infer most of them just fine. Lambda is a step in the right direction and shows they are starting to do it, but really this should just happen for the entire language.</li>
<li>Default parameters and named parameters. When you use this in other languages it feels so clunky in Java to not be able to specify defaults, or have to ensure the ordering of parameters with no hints as to what parameters you are actually using. Overloading is very annoying because of this and could really improve the language as a whole.</li>
<li>Reified Generics, I'm tired of dealing with type erasure. It doesn't bother me for 99% of the things I am working on, but the odd 1% I do it really bugs me.</li>
<li>GPU accelerated Java, I know they are working on it!</li>
<li>An improved JNI interface, the current system is pretty harsh and it really doesn't need to be.</li>
<li>There has been talk about improving the built-in collections to be more efficient and handle large data.</li>
<li>I would also hope they would improve the built-in collections library to support additional types of collections. I.E. Guava Collections and Apache Commons Collections. I would also really like to see some built in support for Graphs, JUNG is nice and all but there really should be something built in for this fairly common data structure.</li>
<li>Implicits or method extensions would be cool as they really enhance a language, but I could live without this. </li>
</ul>
<div>
Ah well, I can continue to dream... </div>
</div>
<div>
<br /></div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-74702264806724963022013-09-21T22:53:00.002-06:002013-09-21T22:53:57.587-06:00Unite 2013 - KSPI almost feel obligated to write a bit more about KSP after watching a <a href="http://www.youtube.com/watch?v=mXTxQko-JH0&feature=youtu.be" target="_blank">video</a> from the Developers talking about some of the various strategies they took to building the game. First of all, I am actually pretty impressed at some of the techniques they used to approach the problems they encountered. Not only did they solve them, they did a pretty good job with it as well.<div>
<br /></div>
<div>
I'm curious as to why they picked using double floating point numbers instead of 64-bit fixed point numbers for the orbital mechanics. I mean precision is really a big deal when dealing with large scales so using something like integers where 1000 represents 1 meter would sound like a better idea. If you used 64-bit signed integers, they can hold 18446744073709551616 values... or more exactly, give you the range of 9223372036854775.808 meters both directions from an origin with 1mm precision. For comparison:</div>
<div>
<br /></div>
<div>
9460730472580800 = 1 light-year</div>
<div>
9223372036854775.808</div>
<div>
<br /></div>
<div>
And you would have highly deterministic 'floating-point' errors at all scales. If you can count 1mm as a floating point error... And if that is the case you could always 'add' more decimal digits.</div>
<div>
<br /></div>
<div>
I do love how the re-entry effects were done, pretty awesome. Even more cool to know the same effects are used for showing high speed air drag and such. The planetary models were done in a very smart way and I have absolutely nothing to disagree with the approach taken. I also found the multi-camera rendering to be pretty cool. Treating each layer separately and then rendering them on top of each other. Considering I had never noticed it, Squad did a pretty good job with it.</div>
<div>
<br /></div>
<div>
I look forward to seeing what else is done with KSP as some really cool techniques have been applied to create a Solar System scale game.</div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-19225526495692938222013-09-20T21:40:00.003-06:002013-09-20T21:40:34.356-06:00The End of Summer!I certainly have been neglecting to write anything on the blog, but I also haven't been doing anything significantly productive for the last while. I spent most of August writing a few mods for KSP in my spare time, and learnt about Unity in the process.<div>
<br /></div>
<div>
<b><u>KSP</u></b></div>
<div>
<br /></div>
<div>
If by any chance someone from Squad does read this post, I love your game and I can appreciate all the hard work you guys have put into it. I also know how you might feel about being 'locked in' to Unity and why you picked it, but I can see a number of issues with your current design and having to rely on Unity.<br /><div>
<br /></div>
<div>
I don't like Unity. It is a great tool for prototyping and rapid application development, but it abstracts away a ton of things you really do need to consider when developing a video game. It also reinforces the idea of poor design by making everything a 'script'. That doesn't mean it won't work, but it certainly is going to cause a number of headaches for when Squad tries to add networking to KSP. I will bet a large sum of money they will not be able to "effectively" turn KSP into a multiplayer game without rewriting significant portions of the game. They may try to get around the issues with their design (some inherited from Unity) by applying some sort of network framework to the game. I'm sure it will work, and you might be able to play with a handful of people, but it will never scale to tens/hundreds of people.</div>
<div>
<br /></div>
<div>
Okay, I am making a bunch of claims and not really supporting any of it. I also am not going to go into too much detail on it or else this post will just be some big long rant. The main concern is the usage of globals and singletons throughout various scripts in KSP. It makes it easy to access various information without any concern for abstraction; however, it forces a crazy tight coupling between various modules, which can sometimes be acceptable. Unity even promotes it by allowing you to access instances of created 'objects' directly. This means your objects are not only tightly coupled, but it gives the illusion of low coupling by not directly showing the dependencies. Now, the reason this will cause issues with networking is because of this design. The game and all of it's modules are expecting to be able to access everything directly with no concern about 'external' updates. This can be cheated (read as 'done easily') by abstracting away the current objects and synchronizing updates to them on the main rendering thread, but its likely going to have a large impact on the performance. Still synchronizing the physics between multiple clients with heavy physics interactions is not something the game is currently setup to handle. It may be possible to have multiple people in the same 'universe' but not be able to interact directly with physics.</div>
<div>
<br /></div>
<div>
The Unity physics engine is very outdated and really needs to be brought in line with the current hardware. It currently runs on the CPU, which is fine for simple things, but really if you want to do simulations the GPU needs to be utilized. Poor Squad, they will have to live with it until Unity is updated to support a more modern 3D physics engine. Another big issue is how textures are handled. As far as I can tell, they are simply loaded individually and applied one by one. Instead, they really should be stitched together and used as a texture atlas. This is really concerning when I see some textures are only having about half (or less) of their data used in rendering. It is just how modern texturing is done... Luckily, KSP is for computers, so the performance is pretty amazing. If KSP tried to run on a console, or mobile device, I would be impressed if a large ship rendered at more than 1 fps. Even on a good computer, I can see some nasty I/O bottlenecks for large ships. CPU running at sub-50% and GPU hardly sweating and my frame-rate is barely cracking 18 fps.</div>
</div>
<div>
<br /></div>
<div>
There are supposedly some performance improvements coming in 0.22 and hopefully those will fix some of the bottlenecks, but performance really looks like it has been left behind and a major focus on features instead. I agree with that approach, but once a few more core components are done there should be some serious time spent looking at performance. Performance is a problem that will keep compounding and without occasionally making improvements it will make the overall game suffer.</div>
<div>
<br /></div>
<div>
<b><u>Libgdx</u></b></div>
<div>
<br /></div>
<div>
After August, I decided to poke around with some libgdx and Scala. Again, I keep getting annoyed by how some key features are missing from Scala IDE (code completion such as generating unimplemented methods in subclasses and javadoc/scaladocs not being shown for any code). I can work without them, but it makes my productivity plummet to the point I could probable write code faster in Java. Another really annoying thing is Gradle integration with Android is pretty much broken for any JVM language other than Java. The issue appears to be a few features missing from Gradle that the Android team want before they can add support for other languages. It really ruins my whole plan of easy deployments; however, everything else with Gradle works great and I will likely switch to it once I can use Scala with Gradle and Android.</div>
<div>
<br /></div>
<div>
Robovm looks like it is coming along very nicely and there seems to be some pretty big support for it. I love the idea of being able to effectively use libgdx to target iOS with native code. I'm happy to wait for it to continue to mature, but I am wondering how hard it will be to integrate that with Gradle...</div>
<div>
<br /></div>
<div>
I am currently in the process of prototyping various designs with libgdx and Scala. I'm also looking at some very awesome <a href="http://www.iforce2d.net/b2dtut/" target="_blank">box2d tutorials</a> and possibly hook it into the <a href="https://code.google.com/p/box2dlights/" target="_blank">box2dlights </a>project as well. My biggest issue right now is figuring out a 'simple' game I want to make. Most of my idea's are way over the top to do alone, and anything simple just doesn't seem interesting enough. I am probably going to settle on making something simple (maybe even just make it open source for the heck of it and allow people to see the source for another game written with libgdx). I am also curious about <a href="http://nextpeer.com/" target="_blank">Nextpeer</a>, as they really look to be filling in that minor issue of 'playerbases' when it comes to Indie games. However, there is also <a href="http://www.scoreloop.com/" target="_blank">Scoreloop </a>(which looks to be dead now) and <a href="http://developer.android.com/google/play-services/index.html" target="_blank">Google Play Services</a> (not sure about it yet, haven't played with it). This is where the whole 'needing some game idea' would be helpful. I would then be able to play with these technologies and get a feel for them.</div>
<div>
<br /></div>
<div>
My most promising ideas at the moment are:</div>
<div>
<br /></div>
<div>
- Restart work on Combatics Evolution (probably start over again as I want to network it and now I actually understand what I need to do to make it happen)</div>
<div>
- Start work on a game inspired by FTL (also network cause that is the part I feel is really missing from the game)</div>
<div>
- Start work on a 2D ARPG with a heavy focus on physics and multiplayer (random world generation and all that)</div>
<div>
- Start work on a simple tower defense, probably single player, but free to play and open sourced.</div>
<div>
<br /></div>
<div>
Ideally, if I had infinite time and no real life commitments... I would do the tower defense, then concurrently work on the ARPG and FTL-like game. After, I would restart work on Combatics Evolution.</div>
<div>
<br /></div>
<div>
It always boils down to figuring out what I want to do and motivating myself to do it.</div>
Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-3869375737074482062013-07-17T19:48:00.003-06:002013-07-17T19:48:53.012-06:00Bullet and LibgdxA long time ago I was under the impression libgdx used jBullet (Bullet 2.72) for the 3d physics. However, to my warm surprise this is not the case at all. It is actually using (Bullet 2.81rev2613) which means its light-years more evolved than jBullet. There are a few other factors that make it better overall, but it uses unmanaged memory with a garbage collector as a fallback. I find it oddly funny how hard it is to find out what version of Bullet libgdx was using. I ended up having to look through the revision history for information on it.<br />
<br />
So maybe this little post will help anyone else who is curious about it.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-67827898193577851642013-07-08T22:42:00.005-06:002013-07-08T22:42:56.089-06:00Modding KSP with Scala<b>TL:DR Just use C# for making addons with KSP, it really isn't worth spending all the extra effort to use a JVM language.</b><br />
<br />
Getting Java 1.7 to work as a mod with Kerbal Space Program is 'easy'. However, the same trick appears to not be able to work with Scala 2.10. It looks like the bridge between Scala and C# is just a bit too far. However, it isn't the end of the world because it still works.<br />
<br />
IKVM.NET is pretty good, it does the job well and actually makes the whole thing possible. However, there is one big catch that really hurts when working with KSP. I'll quote the author:<br />
<br />
<i>First limitation: Currently only custom attributes that have a default constructor or a single one-argument constructor (taking a supported type) are supported.</i><br />
<i><br /></i>
<i>The second limitation is that not all parameter types are supported, only the Java primitive types (where Java's byte maps to System.Byte), type literals, strings and enumerations are supported (and single dimensional arrays of these types). Custom attribute parameters typed as Object are not supported.</i><br />
<i><br /></i>
<u>Java</u><br />
<i><br /></i>
The issue is most things in KSP work by using attributes and thus IKVM.NET will choke on a number of these attributes. However, there is a way around it: inheritance. If you take an attribute and subclass it (to meet the above limitations) IKVM.NET will happily work with the attributes. This does mean you have to write a C# adapter to provide attributes you can use as interfaces in the JVM world. Below is an example of what I mean:<br />
<br />
public class EditorAnyAttribute : KSPAddon {<br />
public EditorAnyAttribute() : base (KSPAddon.Startup.EditorAny, false) {}<br />
}<br />
<br />
Doing all that you can compile your java jar into a dll and slap it into the Plugins folder for your mod, just like you would normally put in your C# dll. However, you also need to put in the IKVM.Runtime.dll and the IKVM.OpenJDK.Core.dll (totaling just over 5MB). If you use some of the other classes, you will also have to provide dll for them as well.<br />
<br />
This means your plugins folder will look like this:<br />
<br />
[mod].dll<br />
[ksp_attribute_layer].dll<br />
IKVM.Runtime.dll<br />
IKVM.OpenJDK.Core.dll<br />
<br />
Pretty gross.<br />
<br />
<u>Scala</u><br />
<br />
Now if you simply try to apply the same process to Scala, it won't work. There is an issue between the annotations generated for attributes by IKVM.NET and how Scala expects an annotation to work. The end result is scalac will complain the annotation is not defined. It will insist it is not defined and cowardly refuse to believe in it. This means you need another adapter in Java to actually use the annotation and then from the Java code you can call your Scala code. Another nice catch is you will also need to use IKVM.NET on the scala-library.jar to use any of the Scala objects, but out of box this doesn't work.<br />
<br />
I'm going to assume I will need to apply proguard onto the scala-library.jar first with my jar file to strip it down only to the tiny bits I'm actually using (sounds very much like the Scala workflow for Android).<br />
<br />
This means if you want to use Scala your plugins folder will look like this:<br />
<br />
[mod w/ java wrapper].dll<br />
[ksp_attribute_layer].dll<br />
scala-library.dll<br />
IKVM.Runtime.dll<br />
IKVM.OpenJDK.Core.dll<br />
IKVM... (other IKVM libraries depended on by Scala)<br />
<br />
At the end of the day, yes you can use Scala to make a mod for KSP, but you are going to have to use 3 languages and 2 tools to make it happen. Your mod is going to be a massive binary blob to even make the simple things run. This means KSP loading time will also be increased by the fact you are now loading a number of extra dlls.<br />
<br />
<br />
In conclusion, you can do it and in order to keep yourself sane you are going to need to automate the whole process because its going to be painful (Gradle for example). Additionally, you will need to write code to fill in the gaps between C#, Java and Scala. Using Java isn't quite as bad and reduces the number of steps required to build a mod, but you still are going to need to use some C# to hook it up for working with some of the attributes. This basically means you might as well just do the whole thing in C# and not spend the time making things compatible.Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com0tag:blogger.com,1999:blog-5958193840511042229.post-71272743961358172682013-07-08T14:13:00.003-06:002013-07-08T14:13:56.503-06:00Kerbal Space Program ModdingAt the time of writing (KSP 0.20.2) modding Kerbal Space Program is actually rather trivial.<br />
<br />
When I say trivial, there is a very nasty catch to the whole modding process. You need to be relatively familiar with some of the Unity Engine code AND you need to be ready to figure out how to use undocumented code. Fortunately, there is a nice guy in the modding community who has come along and helped ease this process by creating some XML documentation on <a href="https://github.com/Anatid/XML-Documentation-for-the-KSP-API" target="_blank">github</a>.<br />
<br />
It isn't really enough, because the documentation is very skimpy and the biggest issue is figuring out how everything hooks together. Of course, if you plan to simply add a few parts to KSP that is a very dead simple and well documented process. On the other hand, if you plan to add a complex new set of features to KSP, you are going to have to learn by example from the source code of other mods.<br />
<br />
If the guys at Squad (people who created KSP) really want to make plugin developers not cry, and do a better job of modding the game, they need to publicly expose some of there API so that modders have a much smaller learning curve.<br />
<br />
I looked at a few mods and re-created the sub-assembly mod to work with the 0.20 plugin system as a test. My next task is to port it over to Scala to test my Scala -> IKVM -> KSP workflow.<br />
<br />
I'm at a disadvantage already because of a lack of experience with C#, but I've used the language before and can easily learn it because of my experience working in a number of languages. Right now I'm really curious to see if I can easily integrate JVM languages as a viable modding option for KSP. I mentioned <a href="http://www.ikvm.net/" target="_blank">IKVM</a> in my previous post, but I also came across <a href="http://jni4net.sourceforge.net/" target="_blank">jni4net</a>.<br />
<br />
My current issue with IKVM is the huge amount of bloat required to simply add a minor feature to KSP (I have to add in 5MB of dll just to log "hello, world" from Java. On the other hand, jni4net acts as a bridge between the languages using proxy classes and is significantly smaller, but its Windows only, requires 64-bit java, etc.<br />
<br />
The end result, my only real option is to use IKVM if I want to develop mods for KSP using a JVM language.<br />
<br />
<br />Jyro117http://www.blogger.com/profile/08283504560254444133noreply@blogger.com1