Not even sure how I found my way here but I did :D mysteries of the internet.
You may be interested in this:
https://bitbucket.org/ekolis/freee
http://spaceempires.net/forum-105.html
Printable View
Not even sure how I found my way here but I did :D mysteries of the internet.
You may be interested in this:
https://bitbucket.org/ekolis/freee
http://spaceempires.net/forum-105.html
In what I can describe only as an extreme failure of documentation, it turns out that using JTA-based transactions with Hibernate is really simple and easy to do, just hard to find out how to do. Puzzling it out involved picking a few needles out of haystacks of search results, and inspecting some decompiled source code of a library or two. In any case, the change for it is now complete and waiting review.
Looks interesting, but I think I'd better stay well away from it. The license terms for copying anything from it into my project are not compatible with my goals for eventual commercial sale, best to try to avoid even the appearance of copying from it.Quote:
Originally Posted by Combat Wombat
Now then, continuing work: I am focusing so far on the technical aspects of the game engine. Next up, I have some TODOs for adding logging and graceful shutdown (currently I have to forcefully terminate the program from the IDE or the Task Manager), and the creation of a technical design document. So, about that design doc, should I go top-down or bottom-up? Grand outline of the entire system with vague details that I slowly fill in, or detailed descriptions of subsystems that I later tie together?
Definitely start with the big picture, but don't spend too much time on it. Get down the bare essentials that you absolutely need, and then work your way down from there. And by bare essentials, I really mean the bare minimum amount of features that you can imagine making the game with. It is incredibly easy to add feature upon feature upon feature, but if the core of your game isn't established first, or even worse if you don't even know what the core of your game is, you're going to run into big problems later on.Quote:
Originally Posted by Douglas
For a Space-Empires type of game, I would say that the bare essentials are: 1) Planets that can be owned, change ownership, and produce resources, and 2) Ships that can be built, move around the map, and attack enemy ships and planets. One type of planet, one resource, and maybe three types of ship (scout, colony and war).
Once you have your core figured out, perhaps even a quick prototype built for it, then you can start thinking about other features to enhance things, like buildings, technologies, player-built ships, races, population, etc. Look at each one at a time, figure out how you'd implement it, what it adds to the game, and how much work it would be. From there, you can decide which ones are good, which ones aren't worth the time and resources to implement, and which ones distract from the core design of the game, rather than reinforce it.
That's not really what I mean when I say "technical design". I'd call what you're talking about "fundamental game mechanics". I'm talking about things like "there will be a server of X nature, a client of Y nature, and they will communicate in Z manner".Quote:
Originally Posted by AgentPaper
So, I was working on technical design documents today, and realized that the design I was thinking of would make it really easy to implement portals between games. As in a ship goes through a warp point in one game and comes out in another (hosted on the same server). Sounds like a crazy idea, and probably incredibly unbalanced, but could make for some fun and weird situations.
On another subject, I'm currently going with lots of short design docs in a hierarchical structure, rather than one large one. Opinions on that choice?
Also, while I technically have the ability to commit changes without review approval, I'd prefer to avoid that. For the few of you actually signed up for code reviewing, please respond promptly every time you get an email about a new or revised change, and don't stay quiet because you don't have any suggestions or someone else already said something. My ideal case is every change having everyone chiming in to say it looks good before I submit. Also, if I revise a change, that requires a new (usually shorter) round of review.
I like Civ, but I almost hate playing on a cylindrical world, any chance of planets based on truncated icosahedra?
http://en.wikipedia.org/wiki/Truncated_icosahedron
Unlikely. It would be easier to have a game based on an actual sphere rather than a rough shape like that. The only real reason it hasn't been done, I think, is because ultimately it wouldn't really change much. The ice caps would still be an impenetrable barrier for most, if not all, of the game.Quote:
Originally Posted by halfeye
The main thing in that shape's favour is that you get hexes almost for free, where you'd need to non-trivially generate them on a sphere.
I don't see that as true at all. In Civ 5 submarines can enter ice hexes. Units being completely unable to cross ice and mountains is unrealistic anyway, both poles of the real world have been visited.Quote:
Originally Posted by AgentPaper
With ice caps at a realistic size you could go around them, which entirely changes the geometry of the worlds.
<edit on 19.4.2015>
No one is interested? oh darn.
Carry on then.
Ok, I think I'm at a point where I can start implementing game mechanics. More specifically, my technical design is at a point where I can treat it as a todo list, and work my way through it one item at a time, but it's all about a framework and I need something for that framework to be used for.
So, I need an extremely simplified game design that will require some sort of use from each part of my technical design but is itself trivial.
When this phase of work is done, I will have a functioning game. I might even release an official build of it for people to play. What would people like that game to be? Keep in mind, the game mechanics have to be simple.
I think hitting the four Xs seems like a good starting point:
1) eXplore, so you need some kind of ship analog that can move around and reveal areas, or at least go to them if there's no fog of war yet. Maybe you can see the places its going but going there reveals the name and some details.
2) eXpand, so you need some way to turn neutral systems into friendly systems. Could be a second type of ship, or something that happens automatically once you have enough population in a system, or whatever.
3) eXploit, so you need some kind of currency that the systems generate, which you then spend on more ships or upgrading your system infrastructure.
4) eXterminate, so you need a way to use your ships to attack enemy ships and systems. Could be another kind of ship again, but could also just require higher numbers of the base scout ship.
Once you have that working and it's fun to play, I think you'll be well on your way to making a great game. Just make sure it's fun before you start adding in more features. If the absolute basic gameplay isn't fun, then you've got a fundamental problem and need to re-think what your base gameplay is (for example, mario is fun with just a runner, pits, and platforms).
If you represent that shape with triangular faces it's a d20 with each face then divided into "thirds" of nine triangles each (180 total triangles from the hexagonal and pentagonal faces). If you keep dividing those triangles to get the desired size of your map then it's not rough at all and equivalent to a wireframe sphere anyway.Quote:
Originally Posted by AgentPaper
No, that's far, far more complex than a wireframe sphere. And keeping track of which triangle each unit is in, figuring out which triangles are adjacent, and figuring out how far each triangle is from another/the best path to move between them becomes orders of magnitude more complex.Quote:
Originally Posted by BannedInSchool
The problem with a sphere isn't the curves; a computer can handle curves just fine. The problem is simply that a grid (and even a hex map is still essentially a grid, with every other row shifted) is far easier and simpler to deal with for a game that relies on discrete positions (ie: you can't have units "in between" squares/hexes/etc), since then you can have unit positions that read X, Y rather than "triangle #2959 that borders triangles #2958, #1506, and #1507"
A sphere becomes much easier if you have continuous movement (no squares or hexes), since you can then save positions as two angles (latitude and longitude) and use those to calculate distance using slightly different, but still fairly simple and quick formulas. And indeed you do see a fair number of games that have this kind of map, for example the recent Planetary Annihilation game.
You can also do this with discrete movement, though you might want three angles (if you have varying height). With spherical coordinates, this isn't that big a deal at all.Quote:
Originally Posted by AgentPaper
Oh, I don't know that it's that bad. Dividing up the sphere recursively into triangles still gives you points with known latitudes and longitudes, the latitudes evenly divided and longitudes divided by a known number at each latitude, decreasing as you approach the poles. Okay, finding neighbors is more complex than just incrementing indices, some points have five neighbors instead of six, and directions get funny as you circle around at a given latitude, but these are challenges to be met and overcome for the glory of doing so, not reasons to abandon the inherent geometric beauty!!! :smallbiggrin: Exact number of points between two arbitrary points? Got me there.Quote:
Originally Posted by AgentPaper
Ships are definitely in, if only to give something for the "player gives an order" system to interact with. I was considering leaving out exploration and fog of war, but I realize now that enabling a good fog of war implementation is a major point in my framework design. So, fog of war is in.Quote:
Originally Posted by AgentPaper
What I was thinking is the brain dead simple "a ship at a planet takes control of the planet".Quote:
Originally Posted by AgentPaper
I was figuring on skipping the middleman and just having planets generate ships.Quote:
Originally Posted by AgentPaper
The primary purpose for this first iteration is to exercise the framework. My ship + enemy ship = no ships does that just fine.Quote:
Originally Posted by AgentPaper
It's been a while, but remember my goal is a Space Empires clone. I'll make my own original game after that, but only when I've got a framework that has proven it can handle full-up SE4, and I think that game has proven it's fun already.Quote:
Originally Posted by AgentPaper
So, summary of what I'm thinking for the initial minimal game:
Randomly generated systems with planets.
Warp points connecting systems.
Fog of war.
Owned planets and ships grant vision of the system they're in.
Players each start with one owned planet (and one ship, so the first turn isn't just "end turn" for everyone).
All planets are the same, and each owned planet creates one ship for its owner each turn.
All ships are the same, and ships can move, go through warp points, and seek after each other.
When ships owned by different players are in the same location, 1 ship belonging to each player is destroyed until at most 1 player's ships remain.
When a ship is at the location of a planet owned by either no one or another player, that planet becomes owned by the ship's owner.
Play continues until only one player remains.
I'm thinking about adding a simple AI that just orders its ships to move to the nearest planet it doesn't own, possibly with checking that no other ship is already going there.
Thoughts and comments?
One specific issue I'm not sure about: Should player identity be separate from empire identity? If I have a bunch of games going on the same server, should I be logging into "Douglas", who is noted as playing empires A, B, and C, or should I be logging into "Empire A", then later separately into "Empire B" and "Empire C"?
Hey this is cool. Who knew looking through an old SEIV LP (SEIV bug just bit me last week) would link me into a cool project?
I am an experienced Java and C++ developer--although, the vast majority of that experience has been me expanding other people's code with absolutely nobody reviewing my work (I tend to be the only software engineer in mixed-specialty projects). As such, I am very good at reading others' code, though I'm sure my style probably leaves much to be desired.
I would very much be interested in contributing to your project, if you are still working on it (been a while since the last update). Also, if you are still taking game design/technical ideas/questions, I have a good batch of those too :).
Would it be an abuse of my moderator authority to retroactively grant permission to necro my own thread? Maybe I should ask the other moderators.
In any case, yes I am still working on this. The lack of updates to the thread is a combination of me not getting anything done on it for a while and not wanting to double post much.
As it happens, I submitted the first change since 3 months ago for review 3 days ago, and no one's given any feedback on it yet. It kinda snowballed a bit, with changes needing other changes needing other changes, so it's a bit larger than usual. I'll send you a PM with details for joining the code reviewer list.
Ideas and questions are always welcome, though I'm not going to take every idea and many of them would be a long way off from getting implemented. Thanks for the interest!
Ah...hmm, I'm not sure exactly, but I believe it has literally been a decade since I last read the forum rules. This thread single-handedly brought me back from a nearly 5-year, GitP-Forum hiatus
A cursory search through the FAQ section doesn't show me what the usual policy toward necromancy is. Anyway, Coding projects should get special dispensation. A month of inactivity definitely doesn't mean a programming project is dead--it takes a lot of time to hack this stuff together in your off-hours :smalltongue:
Anyway, on to comments about the design:
First, why Java? With some of the goals you are setting yourself, it seems like you'll be hammering the CPU for your multi-layered AI decision-making, especially if you want to do some sort of simultaneous processing a-la SEIV. Bearing in mind that I don't really have experience writing resource-intensive Java (on most of the systems I work on, 64MB is a large heap size) I have to ask whether the JVM would be up to the task? Which brings me to...
Second, what model are you planning on implementing for your management AI? I understand right now you're working on simple prototypes for your game, but I think the next step in your development should be working on the AI, since that is a primary goal for your design.
Finally, some gameplay suggestions:
My thoughts kind of get at what everybody has been saying. On of the most fascinating thing about Europa Universalis (which I haven't played, but I've played Crusader Kings which uses a similar concept) is Casus Belli. The idea is, you have to have a justification to go to war, and that justifies how much territory you can take.
Now, I wouldn't necessarily say that you need something as complicated as what Paradox cooks up, but I think it gets at what I'm interested in--namely, that what the population thinks of you should matter, a lot more than it does in current SE. If you are an attacker who wants to take over a planet with a billion+ people on it, you should have two choices: glass the planet, or convince the people living there that they are better off with you.
A stray missile shouldn't genocide millions of people. You shouldn't be able to cram 300 million people into a small transport. Neither should you be able to cram an occupying force able to take a whole planet into a small transport. You aren't invading Poland, you are subjugating a planet when your supply line stretches over light years. Population shouldn't just make a bigger difference in bonuses a planet receives, it should shape how warfare is conducted.
What all this is leading to is this: I like your resources as you have laid them out. Minerals is good. "Production Capacity" should basically translate into "population". Said population will move and breed on its own, with no direct control from the player. The "Operation capacity" (say, "Credits" or something) resource is what you use to encourage your people, to get them to move to the backwater mineral planet and build mines there. The amount of population on a planet would then depend on how much you are paying in incentives an on the living conditions of the planet--if incentives > population, people will move there. If incentive < population, people will move out in droves unless there is a blockade.
If an enemy is blockading a planet, the effect is to greatly reduce the efficiency of the credits being sent to the planet, by making the people unhappy or by reducing production capacity. The defender then has two options--redirect his inefficient resources, which will anger the people on the planet and make it ripe for takeover, or keep sending credits and eat the cost.
How willing the people on the receiving end are to endure the blockade--as well as how willing the people in the aggressor's society are to support such aggression--should depend on how the war has been conducted by both sides. If the aggressor is "justifiable"--i.e. he was initially wronged and he has behaved well (not glassed any planets)--he gets bonus conversion.
Properly balanced, this gives players an incentive to not snowball through his enemies planets, because they are making their lives harder in the long run. Further, it gives more meaning to those cultures you pick when you create a class--basically, the player could define what sorts of actions are going to piss their own people off.
Other random thoughts:
Supply lines sounds interesting. I wouldn't bug with "trade lanes" though, but rather I would come up with some sort of mechanic for holding warp points, like building checkpoints at warp points instead of building space ports on planets determines how well people/goods travel between systems.
I like the idea of organics and exotics as resources. Organics should be high enough to support the population (shortages cause starvation and make people unhappy), but surpluses shouldn't have a major effect without technological development (cloning vats or some-such). I like the idea of exotics as it was presented.
I also like the idea of randomized theoretical research. I also would prefer the idea of research results not being a naive die roll (where every possibility always has the same fixed probability) but rather for the probability for each particular advancement to depend somehow on player action/race choices (i.e. berserkers are more likely to roll weapon research, warriors are more likely to roll armor research, traders are more likely to roll colonization research, etc.)
If you're still looking for reviewers, I'd like to give it a go. I'm trying to branch out from my dayjob in QA test automation (Java/Selenium) and this would be as good a way to dip my toe into interesting code as anything.
Where should general code questions be directed? I don't feel like I should comment on the current build, because I'm still working to grok how the actual code is structured. I wasn't expecting a RESTful application, and while all my Java work revolves around similar software, most of the server stuff is taken care of by a (proprietary) framework.
Here is fine. To quote myself from the OP:
Also note that there is a folder in the root of the repository containing some short design documents, organized hierarchically.Quote:
Originally Posted by Douglas
I don't mind public questions about, for example, how class X fits into the architectural concept design, or why I split function Y into several separate things, etc. You would have to get into extraordinary - and extraordinarily comprehensive - detail for that sort of information to meaningfully reduce the effort required to duplicate my work. Copy and pasting source code is what the NDA is really aimed at.
"The JVM is slow" is, as I understand it, a myth held over from the early days of Java. It was originally true, but has since been rendered false by advances in JVM implementations. So that's it for the negative performance reason to avoid Java.Quote:
Originally Posted by Annon
As for positive reasons to use Java, I know it well, it's portable, and it has a huge array of mature features and free (even for closed-source commercial applications) libraries that I can use.
Yes, AI will definitely be a high priority for me as soon as the basic structure is all in place. I'm currently envisioning two hierarchies, one of analysis classes and one of decision-making classes, with the latter using the former to inform its decisions and each layer in either hierarchy using the next layer down to build on.Quote:
Originally Posted by Annon
I agree completely. This idea will not be in my initial "Space Empires clone" game, because Space Empires doesn't have it, but it's definitely in my plans for my original game. Going to war without your population's willing support should be difficult and cause all sorts of trouble for yourself. Mitigating this, there will be ways to influence your population's opinions - put resources into a giant propaganda campaign for long enough, and eventually your population will fully back whatever action you aimed the propaganda at. Of course, propaganda efforts are trivial for spies to learn about, so a downside of them is your enemy most likely being forewarned.Quote:
Originally Posted by Annon
I think someone calculated once that the amount of space allotted per person in a Space Empires IV population transport, with some fairly generous base assumptions, was a small fraction of the size of a single human body - and that allotment had to cover all the resources to house and feed the population as well as their actual physical volume. SE4 has some serious scale issues.Quote:
Originally Posted by Annon
Ah yes, the concept of migration. I remember seeing that in MoO3 and thinking it was an interesting idea, but poorly implemented. The total lack of control over it in that game was a major problem, especially for players who (for some unfathomable reason:smalltongue:) didn't want their empires eventually becoming entirely inhabited by the race that eats other races for food.Quote:
Originally Posted by Annon
I agree blockades should cause unhappiness, but I've always been annoyed by mechanics that impose arbitrary penalties for blockades - a blockaded planet should have great difficulty getting resources to or from the rest of the empire, certainly, but it should have no trouble at all using its own local resources.Quote:
Originally Posted by Annon
Details will have to be worked out, but I agree in principle.Quote:
Originally Posted by Annon
Hmm, warp point customs offices to protect against piracy and stop smuggling?Quote:
Originally Posted by Annon
Some randomization in research seems realistic and interesting, but it's something I think should be treated with care. Having something delayed a bit by random chance is annoying but manageable, and the accumulation of random influences can lead to more interesting games through diversity of technology among different empires. A bad roll permanently locking someone out of a game changing technology is no fun for anyone, though.Quote:
Originally Posted by Annon
You're also going to need some police boats to enforce that. Not much, they wouldn't be actual military vessels, but building and assigning police boats will help reduce piracy. Of course, it costs money to keep even police boats afloat, so there's a maintenance cost. Still, the reduction in piracy might offset those costs.Quote:
Originally Posted by Douglas
Also, piracy tends to happen on or near borders, outside of civilized areas. So the further inside the Imperial borders, the lower the problem with piracy. You'd still want the police boats around to keep a lid on crime in general and to reduce smuggling (which is near universal).
Might just want to call it 'crime', and have that definition include things like acts of piracy.
This opens up the way for social modeling, at least in basics. The more 'free' a society you have, the harsher the penalties you get for going to war without a damn good reason. The less free a society you have, the more you need to spend on police units (which can simply be a number tally) to enforce your regime or you start getting revolts (perhaps represented by a higher 'crime' stat across the board as 'crimes against the people' get included), but at least you don't have nearly the problems with the proles complaining about whom you are going to war with next.
I'm potentially interested in joining in with this, if you'll have me. I'm currently a second-year university student, majoring in CS/Game Development. I have solid foundations in Java, though almost certainly not on your level.
With regards to the mentions above about a triangle-based grid system for a sphere: Though I don't know about triangles, a hex-grid can actually work perfectly well with standard Cartesian coordinates, no need to track specific adjacency lists, and a triangle grid does form hexes, yes? Just use three axes - see also, a cube viewed with the corner pointing at you.
More on that here. I actually wrote a bit of Java code to work with that last summer, mostly working from that link, to make a variant Game of Life on a wrap-around hex grid, though it's unfortunately toroidal.Code:..._____
../\.....\
./..\.....\
/....\_____\
\..../...../
.\../...../
..\/_____/
Welcome aboard, Qwertystop, you get to watch as I wrestle with Hibernate and automatic maintenance of bidirectional referential integrity. Or, to use less jargon, making sure that (for example) the record for which empires a player plays and which player plays an empire always agree - no matter how my application code goes about changing them.
Should be interesting for you, then. There's a lot of concepts I'm using that I never even heard of until long after I graduated with my CS degree, and I have no idea how much of them have made their way into CS curricula since then. If any of it confuses you (or any other reviewer for that matter), please feel free to ask about it in this thread. I'll be happy to explain.Quote:
Originally Posted by Qwertystop
Hmm, that's some interesting reading. Could come in useful if I use a hex grid, which I definitely prefer over square grids. I haven't decided yet between hex grid and no grid, though. I like the concept of continuous non-integer location values, but I'm not sure how easily I could make it work well.Quote:
Originally Posted by Qwertystop
Is this thing still on? I'm interested in helping. I am Java programmer by day, and could use some flexing. Also I know a bit of Hibernate.
Yes, though work is sporadic. I'll PM you signup details.Quote:
Originally Posted by -D-
I've actually switched from Hibernate to Eclipselink, because Hibernate doesn't have a good way to support multitenancy. Or, for those who don't know what that means, a way to say "I'm looking up data for player 5, no matter what I ask for don't show me anything that player 5 isn't allowed to see."
P.S. I got approval from Roland to declare this thread freely necro-able.:smallsmile:
Have you played SEV, particularly with Captain Kwok's balance mod? Also, while I am a C# dev by trade, I've done Java development (and of course all web front end languages, so Javascript) before, so I'd be up for some code review
I didn't have a lot of coding experience back when you started, but since then I've begin attending university with a major in computer science, specifically targeted at writing in C++ to make games. I'm less familiar with Java, but if you just want someone to look over code I can probably help out. I wouldn't mind getting a chance to look at someone else's game code and to get a bit more familiar with Java as well.
I'm pretty busy this semester so I don't think I could do much beyond reviewing code, but this summer I'll have more time and might be able to contribute to the project more directly as well.
I have a little bit of experience with Javascript but a lot of free time coming up and I would be interested in helping. Is there a particular chunk of functionality that would make a good side project that I could work on in parallel to whatever you're currently working on?
Happy to see some interest.:smallsmile:Quote:
Originally Posted by ebbitten
A few things:
- I'm not actually using JavaScript any more. Switched to Dart a while back. JS has many many flaws, and I thought Dart seemed the best of the "fix JS" languages I could find, and I haven't regretted it at all. So, you might need to learn a new language for that.
- I made this thread to ask for code reviewers, not co-developers. I'm not completely opposed to the idea, but I'd have a pretty strict "match my style and design" policy and I'd still insist on keeping all rights to the resulting project. If that's ok with you, you just want a serious project to learn from, then ok.
- This project has fallen to the back burner for a while, as work takes a lot of my time and I've started working on a separate project - making an AI for an existing game (C-evo if you're curious). That project is in C#, and I wasn't thinking of getting reviewers for it, but I could set that up if you're interested. This new project doesn't directly contribute to the project I made this thread for, but I expect many of the lessons I'm learning, and possibly even large sections of code, to carry over when I get to writing my game's AI.
- When last I did work for this project, I was just starting to create the various UI screens. Seriously, just barely starting on that. If you want to try continuing that while I make my C-evo AI, I might be up for that.