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.
Showing posts with label introduction. Show all posts
Showing posts with label introduction. Show all posts
Tuesday, 23 February 2010
Sunday, 21 February 2010
Project Introduction: Java Simulation Game
While I'm doing some fine-tuning on the MATLAB project before posting the code, I figure now's a good time to introduce the other main project I'm working on. This one's a bit more complex and will probably be in production for ages (an unfortunate side-effect to lack of deadlines).
The simulation game I know and love doesn't really have much in terms of graphics. It's much more a thought-based, economy/diplomacy/strategy simulation, with rules governing interactions, extraction and deployment of resources, and the like. If you have an imagination, it's a real fun game to play because literally anything is possible--you have an administrator or two running it and keeping it balanced, but otherwise if you can think it, it can be done. My version, and all the ones I've played, are sci-fi, galactic empire style games. You rule planets, not cities, basically.
In the versions of these games that I've played, the major downfalls were (discounting admin inactivity and small player base):
The simulation game I know and love doesn't really have much in terms of graphics. It's much more a thought-based, economy/diplomacy/strategy simulation, with rules governing interactions, extraction and deployment of resources, and the like. If you have an imagination, it's a real fun game to play because literally anything is possible--you have an administrator or two running it and keeping it balanced, but otherwise if you can think it, it can be done. My version, and all the ones I've played, are sci-fi, galactic empire style games. You rule planets, not cities, basically.
In the versions of these games that I've played, the major downfalls were (discounting admin inactivity and small player base):
- Problems with cheat-detection. All of these I've played so far were excel-based (or worse, simply forum-based), meaning if a player modified the excel file it becomes tough to notice it.
- Reliance on other players. As all interaction requires a response from someone else, things went slow. For diplomacy and trade, this isn't a problem. But what happens when your fleet is at another player's planet, waiting for the other player to respond to continue the battle, and another enemy comes to your planet knowing you've got no defenses?
- Lack of 'realism.' Mostly in the fact that the player controls EVERYTHING in the past games I've played, which makes playing tougher. Sure, it's nice having absolute say over everything, but it isn't necessary and adds a lot of work.
Therefore I've set out to create my own version of the simulation-style game:
- Programmed in Java, with no access to source code, to prevent cheating but allow essentially any computer to run it.
- More administrator decision-making. A player entering a battle will get to dictate what the general strategy is, what the main targets are, under what circumstances the forces are to retreat, large-scale strategic things like how much of the fleet actually enters the battle to begin with and what remains as mid-fight reinforcements. The defending player then gets told what he knows of the situation (the ships currently in the fray, essentially), and issues main targets and defense objectives. The generals do the micromanaging, and the end result is a battle decision created in a short time through the administrators.
- The concept behind my game in practice is that the leader does leader things. The economy is essentially entirely controlled by the player, but research is done more true-to-life. If a player wants to develop a new fighter craft, they don't tell the admin what exactly goes into it and receive a yes/no answer as to whether it works. Instead, they put the offer out to companies, who create prototypes and bid on contracts, and it's up to the player to choose from a few different options given to them.
Now, some of you may be thinking "this really doesn't sound like fun." For many of you, that'd actually probably be true. This style of game is certainly not everyone's cup of tea. Do bear in mind it isn't simply number crunching. Every action has an outcome on the whole of the galaxy, based on other players' political responses and the NPCs. And a battle doesn't simply go: X ships vs Y ships, Y wins, no ships remaining for X, Y-n ships remaining for Y. It's the administrator's job to narrate, tell a story, and entertain.
Some other features I'll be including in the game concept are:
- Realistic (pythagorean-theorem based) travel times via galactic map coordinates.
- In-depth trading system. All planets will have some of a predetermined list of resources, and most will have their own unique (though questionably useful) resources. Probably will also include a materials market much like the stock market, based on quasi-realistic supply and demand.
- Through the material system, potentially interesting design quirks, waiting to be discovered, in nearly everything. A leader may find a nasty surprise waiting for him when he suddenly discovers his troops are carrying extremely magnetic weaponry, and his enemy knew this before he did, disarming them by way of electromagnets (for a top-of-my-head example).
- By definition, each race will have (aside from preset starting 'equipment') completely unique armies, infrastructures, and economies.
- Dynamic game structure--because the game is coded by the eventual administrator, things can be changed. Want to play a socialist utopia? The economy for your race can be re-coded to be more befitting. For example.
- Espionage that provides both real and incorrect data, and most often time-sensitive. You'll be more likely to find out an enemy fleet's location than its composition. Like the real-world, using acquired intelligence is a gamble that can have huge rewards.
My current status is pretty bleak. The MySQL database structure to go behind it is essentially complete. It's a complex mess of inter-related tables, but it covers essentially everything. The Java work I had done (which was almost nothing anyway) is lost to my last computer wipe, but I've started fresh and am currently at work coding a material property display. Each material has 11 properties, with a range of values from 0-25 (Z-A respectively). I'm working on a 'decoder' that displays the properties in one of those attribute 'star-charts.' The only example I can find easily is this. Imagine the colored section moving around to fill in the shape depending on how high each stat is. Mostly I'm making this for my purposes so I can try to visually see the balance between materials found on varying planets.
Labels:
computing,
game,
introduction,
java,
programming,
project,
simulation,
sql,
technology
Wednesday, 17 February 2010
Boredom and a Whim
What do you get when you cross an engineering student and a boring materials lecture? I suppose if you asked all of the 180-odd students in the lecture theater that day, you'd wind up with at least 50 answers (the most common one being 'Nap time.")
In my case, it was a trip to the library to pick up a "Java book," as it would come to be called. This was (according to my library record) about 2 or 3 months ago. Since then, I've become obsessed with programming (or so I'm told). I stormed through Java basics, swallowed up a decent bit of SQL, and due to an assignment just last week, have powered through MATLAB.
A friend of mine today warned me about mixing work and pleasure, jokingly of course. I've gone overboard on my latest assignment, and it's because I like what I'm doing.
Why aerospace engineering, people ask (and that's not a joke, in those two months, I've been asked this many times, carrying and reading my Java, and later SQL, books at any opportunity). I don't think I could actually do programming for a living. I like it as a hobby, as a challenge. That's what this blog is for: documenting "Charlie's Crazy Computer Coding Capers," hopefully giving and getting hints and tips, and maybe some programming challenges here and there. I'll do a brief summary of my current projects:
- International Standard Atmosphere Calculator (MATLAB), for an assignment due in just a few days. I'm in the home stretch here.
- Sci-fi 'Simulation-Style' Game (Java, SQL), for fun. This was the project that started it all, originally planned as an elaborate excel file and evolving from there. Most of the SQL is complete, Java is still thoroughly in development.
Specific details to come on these later. For now, I'm open to suggestions for projects to try, languages to learn, or whatever else.
Labels:
computing,
introduction,
java,
matlab,
programming,
sql,
technology
Subscribe to:
Posts (Atom)