I have started messing around with Rust and while I am getting a lot out of the experience, I am still getting hung up on the ownership, borrowing, and lifetime models. I feel like I am randomly adding 'as and & until it compiles.

I finally have a solid initial implementation of a Goal planning system. It allows for entities to have goals and subgoals and to replan as circumstances change. A lot of GOAP material available is fiarly complicated from an implementation side, and it took a while for me to get to a simpler system that meets my needs.

On an unrelated note, I now have 1753 mentions on JGO. You all need to stop talking about me and get back to developing games.

Ok (nothing wrong with experimenting!). I don't think it can work that way. You would have to write a custom comparison method. Note, you cannot override the standard equals method as it is final. You could do something like:

In 2014, I gained a lot of knowledge but also wasted a lot of time trying to build half-assed frameworks and tools rather than building a game. My main learnings from 2014 are:

Abstraction and indirection is something you add only when there is a concrete, tangible reason to do so. I blew way too many cycles trying to understand my own code because it was over-engineered up front.

I need to plan better and have time lines for things. Otherwise I just work on a little of this and a little of that and nothing gets done.

I really prefer Intellij to eclipse or netbeans. It's code completion and suggestions are awesome

All of the big 3 IDEs make dependency and source management overly complicated by hiding things behind menu choices and pop up windows.

So for 2015, I have the following goals:

Have my Cribbage game ready to deploy on Android before the end of the year. I have been putting together some milestones for each month, that I am going to try to hold myself to.

Make progress on my space fleet sim. This is the big game that has been in my head and in various pieces for a while now. I am thinking of making as small and simplified version as possible so that I can actually have something playable.

Another potential option would be to use an enum that extends an interface. This gives you the convenience of a global static field while at the same time allowing you to add multiple instances if the need arises.

I am also making a similar game and another thing to take into account is how many units from the same team are attacking a given target. You don't want half of a fleet all going after 2 or 3 small ships just because they are closer. You could maintain a global list of who is targeting who, and query it as part of your algorithm.

My de-generalization / de-abstraction work continues. I had an Action framework where all game entity behavior was encapsulated in concrete actions that inherited from an abstract Action base class that contained code for life cycle management and hooks for concrete Actions to extend. While this had some nice properties, it was hurting my brain from a code organization stand point because I had a proliferation of classes and had to have supporting classes (ActionSystem, ActionEntity) to make it work.

I am working through a much simpler model that won't necessarily give me as much flexibility but will give me what I need now, rather than what I think I may need. If it goes as planned it might be worth a write up in the Shared Code area to get feed back and to also serve as a cautionary tale of the pitfalls over premature generalization.

The fewer classes and interfaces you have the easier they are to organize. Do you have interfaces with only one implementation? Are you programming in flexibility you do not yet need? The more you can get rid of, the easier it is to organize what is left.

One thing I have tried recently which has proved useful is to group classes by cardinality. At a high level, my game has a high Game class which then has multiple GameStates. The game then passes execution to the current GameState. So one package has classes that operate at the Game level (Game itself, GameWindow, InputHandler) and another package has classes at a GameState level (GameState interface, EventQueue, etc). This makes it easier for me to see what "goes together".

I have been going through a process of "De-abstracting" my code. I was running into trouble where I had too many interfaces and too much indirection to the point where I was having trouble following the control flow. I was able to remove almost a dozen classes and interfaces. I may be pushing against the SRP but it is so much easier to understand my code now that more of it happens in one spot.

Koloboke is a higher performance collections library that I have not seen around before. It has the usual primitive collections and claims to perform better than some of the other options out there (like Trove or HPPC). The collections implement the basic Set, Map, and Collection interfaces making them easier to integrate into your existing code.

Today I sighed. Well first I opened my IDE, I looked at my ToDo list, poked around some of my classes, and then I sighed. Every time I work on a project I seem to hit this point where the code becomes this amorphous blob and making changes becomes more and more difficult. This time through I was determined not to let that happen and I have been refactoring and refactoring to (hopefully) so I can keep making progress. I have tried to keep my tasks very small and simple so that I make some amount of progress. I think it is a mental thing more than anything else...

I am home sick but have managed to largely complete my Action system. All of my game entity behavior are wrapped up as Actions which run every update step. So I have a RailGun game entity that has LoadProjectile, ActivateRailGun, DeactivateRailGun, and FireProjectile actions. These actions all inherit from a base Action class and there are method hooks for concrete Actions to override ( onInitialize(), onUpdate, onComplete(), and onFail()). Actions can also have child actions.

I am really liking this approach as it provides a nice, simple way to write and coordinate behaviors amongst multiple game entities.

Points taken. One of the things that piqued my interest in AOP is the ability to possibly consolidate code that might be spread across various classes into a smaller set of aspects. Counter balancing that was the worry about making the same code less comprehensible.

I have recently been taking a look at Aspect Oriented Programming. It seems like an interesting compliment to OOP and I can see some potential uses in game development. Looking at AspectJ it looks like the overhead is all (or mostly?) at compile time with little to no run time overhead.

Has anyone tried AOP programming before and if so what were your impressions?

Scala because it is interesting. Javascript + HTML for the occasional web application at work. I also do a fair bit of SAS programming for work. SAS is a language for statistical computing that is pretty common in the pharmaceutical and financial industries.

For my game I am doing some very simple Graphics2D text rendering while I work on the simulation logic. Due to laziness and taking the "simplest thing that works" approach, my main game class has become an unholy mess of that rendering code, along with other game system level fields and methods. I was able to pull out all of the rendering code (~80 lines in the main game class and 4 other classes), make it a bit more generic, and move it into my game utilities library.

Right now I am trying to figure out how I can better structure some of the higher level systems and fields that I stuck in the main game class.

I understand the basic mechanics of how annotations are created. I was more interested in the purposes people use custom annotations. Are there issues in game programming that people here use annotations to help solve.

I know basically what annotations are and use ones like @Override. I was curious, do people here create custom annotations for their game code and if so why? I feel like I may be missing something here.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org