Felt a bit better today. Still a little more playing around with graphics. I still suck, as if that's a surprise.
Given how Java implements its GUIs, I'm starting to question the usefulness of a visual GUI builder. Every component (essentially) needs to be specifically coded for its task before being placed into the GUI, and the builders don't give much help in that regard. That said, once I actually have the components built, the visual placement of each individual part will be a nice and convenient feature.
More work on the material decoder. I realize decoder is just a word I use because it sounds cool, but I'm sticking with it. Anyway, I haven't gotten far enough to test the output yet because I constantly get distracted, but in theory I'm about at the point where it does what I want it to. I hope to have, at the least, the interpretation graphic working tomorrow, which means the final build of the rest of the piece shouldn't take more than a day thereafter.
All in all, progress made, but not much of note. I'm dedicating tomorrow to working on it.
Sunday, 28 February 2010
Saturday, 27 February 2010
In Sickness
Didn't feel well today. As a sense of pride, I need to post something to keep up my trend. So I'm posting that I'm not actually posting.
Did a tiny bit of attempts at art and programming, slowly closing in on a prototype materials decoder, and now I'm getting still more rest. G'night.
Did a tiny bit of attempts at art and programming, slowly closing in on a prototype materials decoder, and now I'm getting still more rest. G'night.
Friday, 26 February 2010
Making a Series of Menus Look Fun (also: Planet Classes)
Let's face it. Number crunching, data entry, and stat reviews aren't all that entertaining. It doesn't matter if the game they're all for is freaking awesome, it gets boring. I've been thinking about a few ways of making the management of an empire more entertaining even during peacetime.
If I can integrate messages and "forums" into the GUI, it gives the user more incentive to use the program. Also, putting in a chat system, while questionably useful for a small number of users, could occasionally make some entertainment. I intend to play background music, probably without including any files of my own. In other words, the user can integrate his/her own music library.
These features are all long-term planning, probably tough to implement, but they'd be brilliant additions to the game. Less long-term is making the game appear more entertaining.
My current hope is to develop (or find) a series of potential planet textures, as well as moon textures, and show animations of these in the background. When you're looking over your planets, you'll see an approximation of your planet and its moons rotating around. I don't think this will be too hard to implement and at the very least I'll have a static image of the planet in view. I have a friend looking into making them for me, but he doesn't promise anything. I pretended to do some work on it, but I suck with computer graphics. Hopefully I'll find, or have created, a decent set.
That said, if you can't already guess, I got distracted, so the GUI is not in any sort of displayable state.
I can, however, introduce my planet classification system. Avoiding copying a system from Star Trek or similar, I decided to derive my own. So, I give you my system:
If I can integrate messages and "forums" into the GUI, it gives the user more incentive to use the program. Also, putting in a chat system, while questionably useful for a small number of users, could occasionally make some entertainment. I intend to play background music, probably without including any files of my own. In other words, the user can integrate his/her own music library.
These features are all long-term planning, probably tough to implement, but they'd be brilliant additions to the game. Less long-term is making the game appear more entertaining.
My current hope is to develop (or find) a series of potential planet textures, as well as moon textures, and show animations of these in the background. When you're looking over your planets, you'll see an approximation of your planet and its moons rotating around. I don't think this will be too hard to implement and at the very least I'll have a static image of the planet in view. I have a friend looking into making them for me, but he doesn't promise anything. I pretended to do some work on it, but I suck with computer graphics. Hopefully I'll find, or have created, a decent set.
That said, if you can't already guess, I got distracted, so the GUI is not in any sort of displayable state.
I can, however, introduce my planet classification system. Avoiding copying a system from Star Trek or similar, I decided to derive my own. So, I give you my system:
- M[oon] or P[lanet]
- H[ospitable], I[nhospitable], C[olonizable], E[ngineer]
- R[ocky] or G[aseous]
- D[esert], A[rctic], T[emperate], B[arren], F[orest], J[ungle], W[ater], V[olcanic]
- Size (3 digit number, in 1000s of Kilometers (Megameters?))
In other words, a newly discovered planet will probably have a name something like: PHRT-013 and it may have a moon named MCRB-004. Follow the letters into the list above and you'll realize it's a planet vaguely similar to Earth with a moon much the same. Only thing that really needs explanation is the difference between I, C, and E. I means there's no way to settle it at all. C Means you can settle it via domes or other artificial structures. E means domes will work, but you could get more effect out of it if you terraform (sometimes called Space Engineering).
It's not ridiculously inventive or complex but I think it gets the job done. And that's all for now, tomorrow we'll see some sort of actual code progress. I cross my heart.
Thursday, 25 February 2010
CRC Cards and How I Killed a Small Forest
Class, Responsibility, Collaborator. Those are the three things that go onto a CRC Card--the name of the class to be made, what that class does (including what data it stores), and which other classes this class interacts (or, as the name suggests, collaborates) with.
These cards are recommended as a tool for designing an object-oriented program. I do see the usefulness of them. That said, writing 41 CRC cards is not exactly the most entertaining way to pass time. And that includes a couple of cards that I finally decided to generalize, since some things like Ship, Vehicle, and Troop designs all actually contain the same thing and could, as a shortcut, be written on one card.
That said, I haven't gotten to programming yet but I've already seen a payoff from the cards in the form of an organizational hierarchy starting to form. I've got a list of seven classes that don't appear anywhere in the application, but will be great to add in as abstract parent classes. That is to say, I can make these classes with a set format but no data, and then make "child" or sub-classes that take that general structure and specialize it to their needs. It should also allow me to easily compare certain values.
As an example, a station could be built at any point of interest in a system, whether it's orbiting a planet, a moon, a star, or whatever else. Rather than having to store in the station's information both the name of the object it's stationed at and the type of object that is, by having all of these other objects (stars, planets, etc) as children classes to the overall Location parent class, I can simply have the station's location compared to anything that is a child of Location.
This will also work for fleets for current, and target, locations. As I said before, I haven't coded yet, so hopefully it'll work out half as well as I'm imagining it will, but it's nice to see things like this falling into place.
My plan, for the moment, is to develop the GUI class(es) next. I hope to have all of the GUI defined in one class, so that it can share a few easily-redefined variables, and then whenever I need a certain window I'll have the code handling that window call it from the list of already-created objects in the GUI. The intention is that when the user first starts the program, they'll be prompted with a login window where they enter their username and password, as well as being given either a list of display resolutions or a full-on configuration window (depending on how many things there actually are to configure). Personally, I'd like the application to run full-screen, but one of the options will most likely be a windowed mode. I did write up a little "Hello World!" fullscreen application, because I actually was doubtful that Java could even do that. It can, and therefore I intend to work with it.
When I say I'm developing the GUI, I mean the bare minimums. Rather than dealing with test programs for all of my stuff, I'd like to just plug in the code to the GUI I'm actually going to be using. Formatting of that GUI can come later, since as far as the code is concerned, the button can be gray with the word "Exit" on it or it can be a picture of an open door, it's still the same object.
I have a lot of time tomorrow so definitely expect some preliminary work on the GUI to be done for my next post. I might even post screenshots, not that they'll be pretty.
These cards are recommended as a tool for designing an object-oriented program. I do see the usefulness of them. That said, writing 41 CRC cards is not exactly the most entertaining way to pass time. And that includes a couple of cards that I finally decided to generalize, since some things like Ship, Vehicle, and Troop designs all actually contain the same thing and could, as a shortcut, be written on one card.
That said, I haven't gotten to programming yet but I've already seen a payoff from the cards in the form of an organizational hierarchy starting to form. I've got a list of seven classes that don't appear anywhere in the application, but will be great to add in as abstract parent classes. That is to say, I can make these classes with a set format but no data, and then make "child" or sub-classes that take that general structure and specialize it to their needs. It should also allow me to easily compare certain values.
As an example, a station could be built at any point of interest in a system, whether it's orbiting a planet, a moon, a star, or whatever else. Rather than having to store in the station's information both the name of the object it's stationed at and the type of object that is, by having all of these other objects (stars, planets, etc) as children classes to the overall Location parent class, I can simply have the station's location compared to anything that is a child of Location.
This will also work for fleets for current, and target, locations. As I said before, I haven't coded yet, so hopefully it'll work out half as well as I'm imagining it will, but it's nice to see things like this falling into place.
My plan, for the moment, is to develop the GUI class(es) next. I hope to have all of the GUI defined in one class, so that it can share a few easily-redefined variables, and then whenever I need a certain window I'll have the code handling that window call it from the list of already-created objects in the GUI. The intention is that when the user first starts the program, they'll be prompted with a login window where they enter their username and password, as well as being given either a list of display resolutions or a full-on configuration window (depending on how many things there actually are to configure). Personally, I'd like the application to run full-screen, but one of the options will most likely be a windowed mode. I did write up a little "Hello World!" fullscreen application, because I actually was doubtful that Java could even do that. It can, and therefore I intend to work with it.
When I say I'm developing the GUI, I mean the bare minimums. Rather than dealing with test programs for all of my stuff, I'd like to just plug in the code to the GUI I'm actually going to be using. Formatting of that GUI can come later, since as far as the code is concerned, the button can be gray with the word "Exit" on it or it can be a picture of an open door, it's still the same object.
I have a lot of time tomorrow so definitely expect some preliminary work on the GUI to be done for my next post. I might even post screenshots, not that they'll be pretty.
Wednesday, 24 February 2010
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:
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!
Tuesday, 23 February 2010
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.
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.
Sunday, 21 February 2010
Kicking a Dead Horse
My ISA calculator is done. I've left out the US Standard Atmosphere calculations from it, simply because if I were to add it now I'd take the cheap way out of simply converting the input to metric, then the original outputs back into US units. This would be a little bit inefficient and a bit inaccurate, as the different standards are bound to use different conversions than I would. If I ever want to add in that function, then I'll do it proper.
That said, I did change most of the other things I found to be lacking:
That said, I did change most of the other things I found to be lacking:
- Now takes advantage of normalized units, which means the window can be resized (relatively) without problems. Resizing it will allow the table to be viewed without a horizontal scrollbar, and in many situations without a vertical one either.
- No longer recalculates if the values entered at the time of giving it the calculation command are the same as the last values used.
- Fixed a small bug in which if the user clicked the same plot button they were already on, they'd receive a dialog stating "Unknown Plot Type Error." Turns out, the error was simply that none of the plots were selected. If that situation comes up now, it simply returns out of the statement, leaving the last-selected plot in view.
- Pressing enter in a text input box now calculates as necessary.
MATLAB itself has some shortfalls which prevented proper fixes for the recalculation bug and the axis tick mark problem. The first problem is that it's not easy (I'd like to say not possible but that almost always is proven wrong) to have more than one "axes" object in the same GUI. I wanted, originally, to have one set of axes for each plot, and simply hide/show the different axes as requested. Unfortunately, as MATLAB denies me this option, every time the user selects a different plot type, MATLAB has to go through and re-position all of the data points on the set of axes. While it doesn't need to calculate all of the values again, the plotting itself definitely appears to take longer than the calculations, as there's no noticeable decrease in time between inserting fresh values and just switching the displayed plot with the same values.
The second problem was axis tickmarks. The problem here is that the tickmarks have to be manually declared as exact values. While it's not incredibly hard to calculate a vector of values rounded to the nearest thousand or something, the requirements are so contextual to make it a mostly useless bit of extra programming. What happens when the user only wants to see the range of heights from 0 to 25m? From 1276 to 8452 meters? From 0 to 100 meters, in 520 increments? I think you see my point. MATLAB's automatic tickmark decisions are vaguely useful enough to allow them to be the only ones.
So, that said, my work is done.You can find, look over, criticize, and hopefully provide feedback on the source code at this link. I'd expect to hear things along the lines of "it's horribly inefficient," "I'm amazed this works at all," and "YOU SUCK!" so feel free to be brutal, as long as there's some sort of suggestion for improvement alongside it.
Expect to hear progress on my Java simulation tomorrow! Probably a working, if preliminary, version of my material decoder at the least.
Subscribe to:
Posts (Atom)