SQL Concurrency versus JDO, and why I want to make the switch

Small update tonight. I managed to not do much tonight except think. And think. And plan. The outcome is a decision to "scrap" what I have so far on the simulation and start new. Including, (most likely) the database.

And here I was promising the material decoder, huh? Not that it took very long to get nearly finished with that. Another couple of days and I'll probably have that finished, I just need to go through some organization first.

So what am I changing in starting new? Let's go into one of my standard bullet lists:

• (Probably) Removing the SQL from my side of the coding by using Java Data Objects.
• Creating classes for the different objects (like planets and ships) rather than tables per se.
• Truly attempting to take advantage of the object-oriented nature of Java, a la Budd.
• Avoiding so-called "Concurrency" issues
• (Probably) Making the code easier on me to develop.

Java Data Objects, or JDO, are a method of storing entire Java Objects within a database. In my case, by creating a class for each in-game item, I can then store the classes in the database. This becomes useful in terms of the concurrency issues mentioned above. Concurrency in SQL is a problem where multiple users attempt to access the same data at the same time. When one person edits the data, the second person may well overwrite those changes even though the information they based it off of is no longer accurate. Generally this is handled by locking the row, so that only one person can access data at a time.

This is a major problem in my program because of the nature of the database I built, and how it would be accessed. The database is built with 'foreign keys,' or references to other tables, so that all of the data is interconnected. If one user is accessing all of the necessary data to run their empire, then a significant portion of the database is locked up while they're doing that work. Not a very user-friendly methodology. On the other hand, if the planets and ships and everything else are stored as independent objects, the user only accesses those that belong specifically to them and there aren't concerns about simultaneous edits.

I'm not too well-versed in the JDO things yet (I've just stumbled upon them today, really), so I'm not certain, but I do get the impression that using JDO means not needing to use SQL, and this simplifies my coding as well as removing the SQL altogether. Unfortunately, while I've found books that cover JDO, I can't find any at a library near me. I'm considering purchasing a copy somewhere off the web, but for now I'm going to try using the online documentation for it. Until I run into major issues, I'll probably stick with that.

My next couple of days are pretty slim in terms of time spent in-school, so hopefully I'll have a nice structure fleshed out and work started by... the weekend, at the latest? Wish me luck on that!

The Platypus: Object-Oriented Programming Primer

So, about that material decoder. Maybe tomorrow? I didn't have time for much coding today, but I have done some reading. Platty Pat apparently has been given the name Phyl by the author, but I like Platty Pat better so I'm sticking with it.

So what is Object-Oriented programming, anyway? According to this book (I need to give credit where it's due, so the book in question is: "Understanding Object-Oriented Programming with Java" by Timothy Budd. ISBN: 0-321-21174-X for my particular version), it's all about creating code in sections, called objects, which are essentially independent. Each object has its own responsibilities and its own way of accomplishing the tasks set out for it. In principle, there should be only a couple of interconnections between objects, and objects should be reusable from project to project without major restructuring. The program should also be separated such that major feature changes (graphical updates or saving to a different format or what-have-you) should only take updating one or two of the objects, as the other objects don't rely on what's in the other things, but what comes out of them.

I've been reading a bit about the class-oriented nature of Java, which, as I've said in the past, is the biggest part of what the book is about, and the biggest thing about Java I feel I need to understand more clearly. It's the reason there's a platypus on the cover of the book, because if you extend the class structure to real life, the platypus 'extends' the 'class' mammal but 'overrides' some 'methods,' primarily birthing. Anyway, basically a convenient metaphor that sums up a lot of the features of class-oriented programming.

Right now they're going through the design process behind it all, and it certainly is a lot different than what I've done so far--a kind of disappointing fact considering most of the books I've studied have been based around Java, so it would have been nice if it had started with Object-Oriented facets of the language. That said, given my as-yet limited experience with programming, it shouldn't be hard to switch to their methodology, which definitely seems like it would help.

It's interesting stuff and it's something I'm definitely going to take into consideration. Especially on account of the conversation I had today with a friend about my plans for the Simulation. He feels it'd be better for both sides if the administrator was cut out, to save time and all. I'm still intent on allowing complete customization though, which can't be done without the administrator. If I properly program this, I should be able to pretty easily try both. So I guess that's one of my new goals for the project. Keep in mind that one of my favorite things about PC games, and the reason I prefer them to console games a lot of times, is the fact that they can be modified. Mods can extend the life of a game quite astonishingly, and the customization is a key selling point to me. That's probably why I'm so set on making the simulation with the administrator-figure.

Also I managed to stumble upon Google Code, a resource for developers. Apparently a ton of Google's stuff is available for use by independent coders like myself. I might have a go at it sometime, but for now it's conveniently filed away that if I ever have a project that could take advantage of it, it's there to be used.

Quantity versus Quality, Round 1 (FIGHT!)

You'd normally accomplish a lot more in a day than ten minutes, but apparently circumstances make the difference. Yesterday, I accomplished almost nothing. Today, leaps and bounds.

MATLAB still isn't done. I keep getting side-tracked by features that are nice but not necessary. I just finished putting in code to make all of my numbers print in reasonable ways rather than some ridiculous thing like "24.50000" or similar. That said, it is due tomorrow, and all I've got left to do is the relatively easy graphing part of it.

Ten minutes into my work today I tested something I hadn't before: I inspected the full contents of each of my vectors. Turns out they weren't vectors, but rather matrices. This creates a problem as the program couldn't just leave out a whole bunch of values, even if those values were zeros.

Brief walkthrough for those like me. A for loop like the one I posted yesterday will (when made correctly) add a new value to the variable on each pass. MATLAB warns you in advance that this could go slowly, unless you tell it beforehand how long the vector will wind up being. I went ahead and did that by putting in the zeros() function, which fills the vector (or matrix) in with zeros.

I was new to this though and put zeros(length(h)) in for each of these 'vectors.' This actually creates a square matrix, length(h) x length(h) in size. An easy fix, once the error of my ways was realized. By making it zeros(1,length(h)) I told MATLAB to make it 'matrix' with only one value in the vertical direction, or, more commonly, a vector. Then what I originally wanted to do for my table output worked fine, and my table was done.

Quality 1, Quantity 0

In other news, I picked up two new books today at the library. One is about developing games in Java. I keep claiming that's not my overall goal, but it does interest me and the book seems thorough, so I snagged it. The other is about Object-Oriented Programming with Java. While I consider myself pretty good with Java, I've yet to come to terms with what specifically I gain through the OOP aspect of the language. I think my MATLAB work has aided me with it a little, since the two are so close to each other, but hopefully this will help me take advantage of the feature more thoroughly.

On the cover of the latter book is a platypus (complete with fur, duck bill, and eggs) holding a balloon. My girlfriend has named him "Platty Pat" the platypus, and wanted me to share the fact. So, there, fact shared. Oh, and the little guy is holding the book, so a nice case of recursive art.