With Java, it's essentially cut and paste code, or using code generation with templates the way most primitive collection libraries do it.



Isn't another problem with the generics approach is that now you are dealing with Float, Integer, and Double rather than their primitive counterparts?

Not to side track the discussion, but I have toyed with the idea of separate semantically meaningful vector classes (such as units of measure). Ideally you would get a compile time error if you tried to add a Velocity to an Acceleration or something like that.

I haven't thought of a way to do it in Java that reads nicely and has good performance, and isn't a hassle. Phantom types get you a part of the way there but type erasure is a pain. Scala's value classes looks to be a nice approach.

I use the built in SAXParser and found it very easy to work with. Googling SAXParser tutorial should bring up lots of resources.

From this StackExchange answer simply check collisions one axis at a time.

In your case, it may make sense to first check for a vertical collision then a horizontal.

Yup, I was referring more to Jimmt's comment: "...so for example an "Iron Sword" will have the properties (i.e. implement the interfaces) "iron", "melee", etc.".

I could see melee as an interface because it may result in different behavior from a RangedWeapon or a MountedWeapon. It would be good to be an interface because some weapons like spears could be used as MeleWeapon, RangedWeapon, and a MountedWeapon.

In contrast I see Iron as something that affects behavior but does not necessarily have behavior of its own. You might have a base Material class that has properties for strength, potential sharpness, fire resistance, etc. Then have Iron, Glass, Steel, Mithril, etc as either instances of that class or as subclasses.

One place where this may get complicated is when materials can affect behavior. For instance, Iron is meltable, but wood is not. If players can melt a weapon and reforge it into another one, it may get trickier.

I read the links but it doesn't make sense to me that Iron would be an interface on its own. You might have a "Material" interface which has multiple implementations (iron, wood, steel, mithril, etc.). This would at least make it easier to mix and match materials: public Sword(Material material) { ...}.

What I did was create a simple asset library that stores things in a hashmap. At start up, whatever is being drawn reads in the asset library and sets up direct references to the




It's fast, and your Asset Library is only needed when the main objects are created, not at every tick. There is a bit more memory being used because you are holding additional references to the various items in your asset library, but it shouldn't matter (hasn't been a problem for me).

Sounds like the problem is in the code that gets run when a collision is detected. What is the behavior you would like to have? I assume you want the player to stop horizontal motion or bounce backwards. Post the code that is run when a collision is triggered and it will make it easier to see what the problem is.

EDIT: Another question. Does your game code know when a horizontal collision has occurred vs. a vertical one?

Are you writing to the file because you want to view the file, or is it just a way of storing things on disk? If it's the latter, then you may want to look up object serialization.

Another option, if case doesn't matter is to simply set the input to lower case up front.



Now you don't have to worry about using equalsIgnoreCase() everywhere.

Decoupling the Library from the Renderer is more important than the saving of the intermediate step. OOP does seek to de-emphasize the scope and use of global systems, so I think what you are trying to do is perfectly reasonable. A lot of times you end up with a System that manages a set of Child classes where all of the logic is in the System and the Child classes end up being little more than data containers. Often times you can push much of the System logic into the Child classes and have the Child classes more responsible for their own behavior. This is a more OOP approach, at least as outlined by David West's Object Thinking.

I did this with my Event system and I am much happier with the design. My Events were nothing but data containers and my Message System did all the work. This meant that every object that sent messages needed to know about the EventSystem itself in addition to the Events it wanted to send. After I refactored my design, the objects only had to know about the events they wanted to send, and the EventSystem was simplified to the point where I was able to get rid of it entirely and simply put Events in my queue of things that get updated every tick.


In your specific case, I think storing the Sprite in the object itself makes sense but there are some things to consider:

1. If there are a lot of objects of a given type that all use the same sprite, you are going to use some extra memory because each object will hold a reference to that sprite. It probably won't be a big deal, but it is something that might be important depending on how many objects you have on the screen at a time.

2. If you are not careful, you may make things more confusing, not less. Right now, your SpriteLibrary is coupled to your Renderer. You don't want your SpriteLibrary to be directly coupled to every concrete GameObject. If you have a base GameObject that everything inherits from, put the reference in there.

3. You may want to go even further and have the Game Object responsible for rendering itself. So the Renderer calls mrMushroom.render(x,y). This is in line with Behavioral OOP as described by David West in Object Thinking where the object is responsible for its own behavior.  How worth while this is depends on how complicated your rendering is.

In the course of developing my game, I have felt the need to start over multiple times and in every case it has been because I was unable to handle the complexity of the code base. As the code size and number of classes grows beyond a certain point, it all starts to look like a like a ball of mud. I don't know how and where to make changes and I get a sort of numbness to the whole thing. I have been trying to improve the situation by:

1. using pre-existing libraries more
The less code you write, the less there is to manage.

2. Limiting dependancies.

3. Improving my documentation.

4. Separating out "framework" code from game specific code.
I have a separate Eclipse project for code that isn't necessarily specific to this game. For instance, I have a Bag/Multiset implementation defined there as well as an Event/Messaging system.

While this has all helped, with my current iteration of the project, I have started getting that same sinking feeling and I want to stop it before it gets out of control. Some things I haven't really tried that may help:

1. Organize my packages by something other than "type of thing".
I put all of my entities in an net.actual.entities package. I'll put events in a net.actual.events package. While this helps in one sense, in others it doesn't. For instance, certain types of entities and events tend to be used together. Maybe I should organize packages by application layer?

2. Try to split more of the code out into separate projects.
Mentally it may help to look at fewer classes at a time, but I wonder how many independent pieces there really are.

3. Try to use a more data driven approach.
May lower the total class count and allow for the game to be defined using configuration files that could be simpler than the equivalent code.

4. Diagramming the system at a higher level (UML?)


Any thoughts? How do you architect and/or organize your code and keep it understandable as a whole?

I think you answered your own question :).  

Making each tile an instance of a class makes sense and it looks like you have a reasonable and workable solution so I would stick with what you have unless some issue (performance, complexity, etc) forces you to change.


If you are still wondering if you have the right approach, it is worth thinking through a couple of scenarios that you plan for your game to see how well your current set up will handle it.
1. Will the player be able to rotate the board as a whole and/or zoom in and out? If so, do you think your current set up will be able to handle it?
2. When you have things on the tiles (units, buildings, whatever), will your setup be able to handle that. For instance, if the top of a building overlaps with a title and the player hovers over it, will your setup be able to detect that?

As an aside, I like the idea of the volume of the tile being highlighted as you hover over it (maybe as a colored translucent cube borderless cube).

In general the second way is correct. There is a phrase in programming "Program to an interface not an implementation". It makes it easier to swap out different implementations. This StackOverflow question contains a lot of information.

In short, your code will be more flexible and easier to change with the second approach. For instance, if you end up creating a "MyThread2" class and decide that myThread should be an instance of that, all you need to do is to change the code where it's constructed.

Not to sidetrack the discussion, but I wouldn't necessarily call this filtering. Whenever I have heard the word filter used in programming it has been to drop items from a collection according to some predicate. What you have is more of a map. You have an input set of values that maps to a smaller set of output values.

If you search java map range of values in Google, some interesting things come up. If the number of "buckets" is fairly small and there are no "holes" then the simplest would be to store two arrays. One which has the max range of each bucket, the other which has the output value.

Then you could do something like:




This doesn't take advantage of equally spaced slices but it should be plenty fast. If you have a large number of buckets, it may be worth while doing some sort of binary search type set up to reduce the number of comparisons.

pron,

Thanks, I'm not sure how I missed it. I look forward to playing with it.

spasi,

Thanks to the pointer to Disruptor. I haven't heard of it before.

Interesting stuff. I see in your blog post the code examples are in clojure. Do you have equivalent examples in Java?

I have found myself moving towards classes with fewer but longer methods. The main reason for this is thinking about objects in terms of domain behavior rather than data + functions.

* I no longer reflexively create getters and setters for all of my fields. I only create one if it is absolutely necessary.
* I no longer write methods "just in case". I don't write a method until there is behavior that I actually need that doesn't currently exist.
* I no longer preemptively break methods into small pieces. I only pull code out of a method if that code is going to be called from multiple places, or if it's something that needs to vary between subclasses.
* I take "Tell don't ask" more seriously.


I found that doing this has made my code easier to understand and the interactions between objects are simplified.

Have you tried something simple like make small program that when you touch the screen it starts counting the number of seconds?
This way you could better isolate if the issue is with your time step or with the render/easing function.

I prefer not to use singletons/static methods because it makes my code less OOP-like and more procedural which (for me) is harder to reason about. I have never personally had a case where I accidentally created additional instances when I only mean to have one. My biggest driver is that I have some service that is needed all over the place and a public static reference is just very convenient. I have not found an alternative solution to this that was satisfactory other than to try and design my code to limit the scope these static fields/methods need to have.

I wonder if one thing you can do is put the player in the middle of the screen and then place an enemy at every single pixel on the screen. If renderMe is true then draw a red pixel for that enemy, if renderMe is false then draw a gray one. This will give you the full picture of where your algorithm is working and where it isn't.

You don't necessarily have to put an actual enemy, just iterate through all of the points on the screen.

Some scattered thoughts:

What are the odds that you will accidentally create a new rendering system, audio system, or game instance? I would guess it would be pretty low and so it shouldn't be something you spend a lot of time worrying about.

The order of operations issue you raise will happen whether you use singletons or not.

The issue seems to be more one of convenient access. You have these "system" classes like rendering and sound and you need to be able to get at them easily from anywhere in the code base.

The problem I have with singletons is that they become global variables and as such they tend to get used everywhere. This means your classes may have lots of dependencies and becomes harder to reason about. They can also reveal too much about how something is being done. It is sometimes better to better to hide "System" classes and reduce their scope.

As an example, my game uses message passing. So I had a base Event class from which concrete events (ExplosionEvent, ShipArriveEvent) inherit. These were all managed by an EventSystem. Because anything could send an Event, I made the eventSystem a public static field in my game class. I used it like so:



A couple of issues:
1. The Missile (and anything else that sends an Event) is coupled to EventSystem.
2. The Missile is also coupled to MyGame because it needs to be able to get the eventSystem reference.
3. Why does the Missile care about how Events are sent?

So I made a few changes. I created a private static EventSystem field in the base Event class and added a public static setEventSystem() method. I also added a "post()" method to the Event:



The dependancy is hidden within the Event class. The only thing senders care about is the specific Event they are creating and, semantically, "post()" exists at a better level of abstraction than "eventSystem.addEvent()".

How big of a difference does this make? In this one case, not a huge difference, but as globals and systems pile up, it can start to add up.

You might find this article useful.

System.gc() does not guarantee that a garbage collection will take place at that moment. It simply "suggests" it to the JVM, so the GC may or may not actually happen. From the api:

"Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects."

The diamond operator is just a convenience so you can write List<GameObject> myList = new ArrayList<>(); instead of List<GameObject> myList= new ArrayList<GameObject>();.

Typical EC systems have very little to no hierarchical structure. . They are rarely tied in parent/child relationships and are almost never used with inheritance. Although Assets may be stored by components, usually the Assets (as well as the UI, Input, and the Scene) are not Entities themselves.

This is a pretty good discussion about Components.

I wanted to write my own "Colossal Cave" which was the first game I had played on a computer.

I used BASICA because that's what the IBM PC had, and I didn't know there was anything else. Now I use Java because it is what I am most familiar with and it has good enough performance for the type of games I want to make.
I think I was around 8 or 9. Now I work at a pharmaceutical company and do data programming in SAS as well as application programming in Java and Scala.

Personally, I learn best when I understand things at a more theoretical / abstract level. Code examples don't help me as much if I don't have the foundation ahead of time, so someone pasting in some code and saying "do it like this" is not as helpful as it might be with others. Recently I have gotten a lot out of the books Object Thinking and Holub On Patterns. They showed me that although I was using objects and classes, I wasn't really taking advantage of what OOP has to offer. I was really just doing procedural programming in Java. Going over my game/work code with these books in mind have been a revelation for me. My code has immediately gotten more readable and more understandable.
Write something small.....trivially small, but finish it.
A simple text based roguelike.

what does levelX and levelY hold? My assumption was the X and Y position within the level. is it the height and width?

While not libGDX, I have found these LWJGL tutorials to be pretty good so far.

A couple of questions:

1. Who do you envision as modding your game? Other programmers? People into your game who can't program?
2. How much of your game do you wish to be moddable? Different art assets? Different behavior?

This will help you decide what kinds of tools to use. If you want non-programmers modding your game, you are going to have to either provide tools or give them access to something they can understand.

And why are you hung up on keeping your source code secret? Is it to prevent cheating?

That is a pretty broad question. I think your options with Java are similar to most other languages.

You can provide a tool (like a level editor, etc) that allows people to make modifications, although that can be a fairly complex task to develop in and of itself.

Another option is to take a data driven approach. For instance, use external configuration files rather than hard coding values. If you want to take this to the extreme, then you can use the Properties Pattern (Steve Yegge has a pretty good description of it). You essentially store everything in hash maps rather than fields.

So you don't have a Ship class any more. Everything is a bag of properties. This can give a lot of freedom to specify all sorts of behavior outside of your code.

The down sides of the approach are that the performance may not be as great, it can get unwieldy to program (lots of getValue("hitPoints"), and you can't take advantage of the static type checking that Java gives you.  If your property is maxHealth and you call it maxhealth, you won't know until run time.

When you play it, you'll see .