Simple Standalone Engine Project

Alfryd · 29-06-2009, 02:10

I'm posting this here in the hope of attracting any other modders that might drop in from time to time, because this is only loosely related to Maj2 itself- I've been working for some months now on a relatively simple engine for a standalone game.

It's not much to look at right now, but it has most of the basics for implementing Maj1's gameplay and (hopefully) supports rapid prototyping: It has 3d terrain generation, can handle either 2d-isometric or 3d sprites, has hierarchical A* pathfinding and some basic underlying UI functions (buttons, menus, text display, etc.) It's still rough around the edges and lacking in various essentials (fog of war, event listeners, save/load routines,) but- in short- it's gotten to the point where I can reasonably worry about gameplay.

Partly, this is a reflection/extension of work I did on the abortive java client for Heroes of Ardania, but I was prompted to try and come up with an independant engine when I realised that the devs of Maj2 were... unlikely to offer adequate scripting tools for custom AI, and I'm not waiting another 8 years for it. I'm hoping to eventually leverage clojure as a scripting language for hero behaviour instead, as it offers impressive expressive power, decent performance, and solid JVM integration.

But, for now, I'm just leaving this thread up for anyone who wants to get in contact here and potentially work on this. One possibility would be to extract the art and sound assets from Maj1, port those to the new engine and use those to experiment with new/extended gameplay and a revamped AI- alternatively, those could be phased out gradually in favour of full 3D versions/new art. It IS very early days, so do PM me if interested.

Mantic · 29-06-2009, 04:28

Sounds like you've already done some good work here. Kudos!

PM'd you about possible contributions.

Alfryd · 29-06-2009, 17:11

Much obliged.

Alfryd · 01-07-2009, 13:22

Repost from the HoA forums:
http://z13.invisionfree.com/Heroes_o...934&st=0&#last

Quote:

Again, not much to look at, but you can see some of the housing development and walkers going about the place here. Again, this is all crude placeholder art, and I'm aiming to redo these in 3d later.
...I really need to get some peasant models.

Alfryd · 03-07-2009, 13:41

I'm reposting a couple of points from my exchanges with Mantic for general information:

Quote:

1. I may not be talking about literal cloning of majesty's buildings/characters directly into 3D- what I want to preserve (and possibly build on) is the underlying gameplay mechanics, while keeping the overall art *style* similar to Maj 1.

2. I'm not aiming for cel-shading- my concepts are just rough sketches I touched up in photoshop, there to give some idea of the overall shape and colour scheme. Feel free to embellish/improvise!

3. The animation system I have implemented at present relies on joint-based keyframes with quaternion interpolations (mainly because that's what .ms3d uses.) There are technical pros and cons to this approach, but I'll probably stick with it for now.

4. I have quadtree-based scenegraph culling implemented, and it works fairly well, but I'm not going to be implementing 1st-person perspective (or perspective of any kind, for that matter.) I may not even be implementing a zoom/rotate feature (or, if I do, it will probably be modest- maybe a 3x difference between min. and max. zooms)- for the very reason that zooming in close puts pressure on the artists to provide high-resolution models and textures (and LOD) where gameplay benefits are minimal. Functionally, it will look much the same as 2D-isometric (which also allows us to incorporate 2D sprites more seamlessly.)

5. Things like shadow buffers and reflection maps are on the list, but way, way down- among other things, they mandate a complete transition to 3d.

6. Basic poly counts for the characters need to be as low as possible- ideally under a thousand polys. This is one of the cons of using joint-based animations on older machines without shaders.

Alfryd · 07-07-2009, 02:02

Ladies and gentlemen, we have (basic) fog of war:

Save and load functionality is implemented but untested, and I still have to work out some form of collision-checking, but the terrain generation algorithm has been tweaked to give more reasonable results, so that's some good news. Hopefully, I'll have something vaguely recognisable as majesty-like by the end of the month.

Marchris · 07-07-2009, 04:21

Hey Alfryd. Got yourself knee-deep in another Majesty project, eh? Good to see you are still at it.

I have replied to your PM, just voiced added support here.

I'd be interested to sit down and figure out how we could facilitate getting some new models into your engine.

Quote:

Originally Posted by Alfryd

3. The animation system I have implemented at present relies on joint-based keyframes with quaternion interpolations (mainly because that's what .ms3d uses.) There are technical pros and cons to this approach, but I'll probably stick with it for now.

Ever since Dungeon Siege, Quaternions have scared me, but overall, that's a pretty robust sounding animation system, the only real problems I can forsee at this point might be baking feet animation properly, and any other situation that involves an agent interacting with an inanimate object in the game world. ('sliding feet' and such that breaks the believability of a game)

Quote:

Originally Posted by Alfryd

6. Basic poly counts for the characters need to be as low as possible- ideally under a thousand polys. This is one of the cons of using joint-based animations on older machines without shaders.

I actually like the challenge of limited poly counts, I think a lot of current generation games quite rather squander their generous limitations.

Alfryd · 08-07-2009, 14:26

Great to hear from you, Marchris- I've given more info by PM.

Alfryd · 10-07-2009, 14:54

I'd also like to talk a little bit about Clojure here, because it has a number of features that, I think, could make it very, very useful for AI programming in particular.

First off, Clojure is a dialect of LISP. For those unfamiliar with the language, the key thing to understand about LISP is that it treats it's own programs as data structures to be manipulated, rather than text files to be parsed- in other words, LISP programs can dynamically rewrite themselves during execution. This is important enough that it bears repeating: In LISP, you can write programs that themselves write programs. The implications for AI research should be obvious, and that's what LISP has been used for, certainly for decades. Most of the existing dialects, however, suffer from an insular mindset, a paucity of libraries, and relatively slow execution speed- the overhead involved in upholding the 'code as data' philosophy means that a given LISP will run anywhere between 2x and 100x times slower than native code.

Clojure is built directly on the JVM, which means it can freely access all existing Java libraries, call Java routines (and vice versa,) and take advantage of the speed benefits of Hotspot compilation. Clojure can theoretically- with the right type hints and method structure- compile directly to native functions and run as fast as either C++ or Java. (In practice, using the interesting features of the language means running at about 1/10th native speed, but that's still pretty decent for a scripting language! Besides- there are certain things which a Java or C++ program simply cannot do without, effectively, reinventing themselves as LISP.)

Data structures in Clojure are immutable. This means that nothing you define ever changes- you simply create new versions of old objects that share common state (and afterwards shuffle around the references to 'em.) Why is this handy? Basically, because it should allow intelligent agents to cheaply 'imagine' hypothetical consequences to their actions- essentially create new versions of the world which represent exactly that. AI programming involves a huge amount of this kind of tentative exploration of the space of future possibilities: A* pathfinding is just a special case, so being able to model more complex interactions accurately and economically could be of huge benefit.

Data structures in Clojure are efficient. Clojure hashtables- despite being a direct part of the language syntax and the overhead required for 'versioning'- are faster than their java counterparts. Their access time growth is Log32 N- small enough that it's insignificant- and grow in constant time. (This is because they're not actually 'hashtables'- they're binary tries. Details here.) In addition, every object can be used as either a key or value for insertion purposes. The generic AI system I worked on before relies heavily on hashtable access, so having this kind of fast, flexible mode of ingress is a blessing in itself.

Anyways, this is all still theoretical- I'm only just starting to hook up the Clojure routines for skill checks, etc. on the simulation side of things- but it should give some idea of the possibilities that this approach holds for some very robust AI.

DeathWind · 21-07-2009, 04:30

Oh my, Alfryd, how do you manage to make these pictures?! They look fantastic! Do you use Adobe Photoshop or some other program? I am merely curious.

Quote:

Originally Posted by Alfryd

I'm posting this here in the hope of attracting any other modders that might drop in from time to time, because this is only loosely related to Maj2 itself- I've been working for some months now on a relatively simple engine for a standalone game.

Eh, are you saying our Majesty, both the original and the expansion, can be modified? Or are you saying that for Maj II?
Or are you making a completely new game, separate from, though based on, Majesty?

Spiderman · 21-07-2009, 13:17

I think he's saying anyone with mod experience in other games, not Majesty, since that isn't moddable.

Alfryd · 21-07-2009, 17:05

Quote:

Oh my, Alfryd, how do you manage to make these pictures?! They look fantastic! Do you use Adobe Photoshop or some other program? I am merely curious.

Eh, the usual method- sketch, scan, contrast, color multiply. paper + photoshop. Thanks, in any case! I'm coding a new engine essentially from scratch (albeit based heavily off earlier work from other projects.)

Also, Mantic- please PM me with the new art

Glorfindal · 27-07-2009, 17:00

Hi, Alfryd you probably remember me from the HoA Dev Forum. I was just curious if you could show a screen of the entire interface. And are you programming this in Java or C++?

Alfryd · 27-07-2009, 17:26

Hey, Glorfindal- this is being programmed in Java. There's not much to see of the user interface at the moment- just some basic buttons for building/road placement, the attack flag button, and a minimap-

I've also decided to stick with a flat world for now, since it greatly simplifies placement of roads, walls, cropland, etc... at present, I'm working on placement of lairs and player starting locations- once that's done, I can start generating monsters and implement hero hunting behaviour.

Glorfindal · 27-07-2009, 19:21

That's really cool! I know a lot of C++. And I tried Java but could never really understand it. What Java compiler are u using or did you download the JDK and compiling it in Javac? I tried Finding the JDK but I could never find where to Download it. Also by saying the word Flat do u mean 2D?

Alfryd · 27-07-2009, 19:30

I'm using the Eclipse IDE about 99% of the time- the JDK shouldn't be hard to come by, try here. By Flat, I mean no height variation- no hills/valleys, etc. -At least for the present. If you want to help out with development, PM me and I'll see if we can work something out.

Glorfindal · 27-07-2009, 19:54

I went to the link you posted. But all I saw was updates I couldn't ever find the actual copy.

T'pek · 27-07-2009, 20:15

Just noticed this topic listed on the main forum page.

This looks very interesting. Is it open source?

It'll be interesting to see a game coded in Java. Most games are done in C++, but using Java means you don't even have to make a different build for every platform.

And as for you Glorfindal:
http://www.eclipse.org/downloads/

Eclipse is a very good development environment for Java (and other languages), and there most good others are built upon it.

Peter Ebbesen · 27-07-2009, 20:18

Glorfindal, the updates are the entire SDK, highest update number being latest revision. Just download the Java SE Development Kit 6u14.

Glorfindal · 27-07-2009, 20:43

Thanks both of u but is there any version of eclipse for Windows?

29-06-2009, 02:10	#1
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	Simple Standalone Engine Project I'm posting this here in the hope of attracting any other modders that might drop in from time to time, because this is only loosely related to Maj2 itself- I've been working for some months now on a relatively simple engine for a standalone game. It's not much to look at right now, but it has most of the basics for implementing Maj1's gameplay and (hopefully) supports rapid prototyping: It has 3d terrain generation, can handle either 2d-isometric or 3d sprites, has hierarchical A* pathfinding and some basic underlying UI functions (buttons, menus, text display, etc.) It's still rough around the edges and lacking in various essentials (fog of war, event listeners, save/load routines,) but- in short- it's gotten to the point where I can reasonably worry about gameplay. Partly, this is a reflection/extension of work I did on the abortive java client for Heroes of Ardania, but I was prompted to try and come up with an independant engine when I realised that the devs of Maj2 were... unlikely to offer adequate scripting tools for custom AI, and I'm not waiting another 8 years for it. I'm hoping to eventually leverage clojure as a scripting language for hero behaviour instead, as it offers impressive expressive power, decent performance, and solid JVM integration. But, for now, I'm just leaving this thread up for anyone who wants to get in contact here and potentially work on this. One possibility would be to extract the art and sound assets from Maj1, port those to the new engine and use those to experiment with new/extended gameplay and a revamped AI- alternatively, those could be phased out gradually in favour of full 3D versions/new art. It IS very early days, so do PM me if interested. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands.

29-06-2009, 04:28	#2
Mantic Recruit Join Date: Jun 2009 Posts: 2	Sounds like you've already done some good work here. Kudos! PM'd you about possible contributions. Last edited by Mantic; 29-06-2009 at 04:42. Reason: *

29-06-2009, 17:11	#3
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	Much obliged. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands.

07-07-2009, 02:02	#6
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	Ladies and gentlemen, we have (basic) fog of war: Save and load functionality is implemented but untested, and I still have to work out some form of collision-checking, but the terrain generation algorithm has been tweaked to give more reasonable results, so that's some good news. Hopefully, I'll have something vaguely recognisable as majesty-like by the end of the month. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands.

08-07-2009, 14:26	#8
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	Great to hear from you, Marchris- I've given more info by PM. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands.

10-07-2009, 14:54	#9
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	I'd also like to talk a little bit about Clojure here, because it has a number of features that, I think, could make it very, very useful for AI programming in particular. First off, Clojure is a dialect of LISP. For those unfamiliar with the language, the key thing to understand about LISP is that it treats it's own programs as data structures to be manipulated, rather than text files to be parsed- in other words, LISP programs can dynamically rewrite themselves during execution. This is important enough that it bears repeating: In LISP, you can write programs that themselves write programs. The implications for AI research should be obvious, and that's what LISP has been used for, certainly for decades. Most of the existing dialects, however, suffer from an insular mindset, a paucity of libraries, and relatively slow execution speed- the overhead involved in upholding the 'code as data' philosophy means that a given LISP will run anywhere between 2x and 100x times slower than native code. Clojure is built directly on the JVM, which means it can freely access all existing Java libraries, call Java routines (and vice versa,) and take advantage of the speed benefits of Hotspot compilation. Clojure can theoretically- with the right type hints and method structure- compile directly to native functions and run as fast as either C++ or Java. (In practice, using the interesting features of the language means running at about 1/10th native speed, but that's still pretty decent for a scripting language! Besides- there are certain things which a Java or C++ program simply cannot do without, effectively, reinventing themselves as LISP.) Data structures in Clojure are immutable. This means that nothing you define ever changes- you simply create new versions of old objects that share common state (and afterwards shuffle around the references to 'em.) Why is this handy? Basically, because it should allow intelligent agents to cheaply 'imagine' hypothetical consequences to their actions- essentially create new versions of the world which represent exactly that. AI programming involves a huge amount of this kind of tentative exploration of the space of future possibilities: A* pathfinding is just a special case, so being able to model more complex interactions accurately and economically could be of huge benefit. Data structures in Clojure are efficient. Clojure hashtables- despite being a direct part of the language syntax and the overhead required for 'versioning'- are faster than their java counterparts. Their access time growth is Log32 N- small enough that it's insignificant- and grow in constant time. (This is because they're not actually 'hashtables'- they're binary tries. Details here.) In addition, every object can be used as either a key or value for insertion purposes. The generic AI system I worked on before relies heavily on hashtable access, so having this kind of fast, flexible mode of ingress is a blessing in itself. Anyways, this is all still theoretical- I'm only just starting to hook up the Clojure routines for skill checks, etc. on the simulation side of things- but it should give some idea of the possibilities that this approach holds for some very robust AI. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands. Last edited by Alfryd; 13-07-2009 at 21:10.

21-07-2009, 13:17	#11
Spiderman Major Join Date: Jul 2007 Posts: 581	I think he's saying anyone with mod experience in other games, not Majesty, since that isn't moddable.

27-07-2009, 17:00	#13
Glorfindal Recruit Join Date: Nov 2008 Posts: 8	Hi, Alfryd you probably remember me from the HoA Dev Forum. I was just curious if you could show a screen of the entire interface. And are you programming this in Java or C++?

27-07-2009, 17:26	#14
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	Hey, Glorfindal- this is being programmed in Java. There's not much to see of the user interface at the moment- just some basic buttons for building/road placement, the attack flag button, and a minimap- I've also decided to stick with a flat world for now, since it greatly simplifies placement of roads, walls, cropland, etc... at present, I'm working on placement of lairs and player starting locations- once that's done, I can start generating monsters and implement hero hunting behaviour. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands.

27-07-2009, 19:21	#15
Glorfindal Recruit Join Date: Nov 2008 Posts: 8	That's really cool! I know a lot of C++. And I tried Java but could never really understand it. What Java compiler are u using or did you download the JDK and compiling it in Javac? I tried Finding the JDK but I could never find where to Download it. Also by saying the word Flat do u mean 2D?

27-07-2009, 19:30	#16
Alfryd ...It's nice up here! Join Date: Jul 2007 Posts: 1,516	I'm using the Eclipse IDE about 99% of the time- the JDK shouldn't be hard to come by, try here. By Flat, I mean no height variation- no hills/valleys, etc. -At least for the present. If you want to help out with development, PM me and I'll see if we can work something out. __________________ I we please you, tell others; If not, tell us. ...Yes, I have too much time on my hands.

27-07-2009, 19:54	#17
Glorfindal Recruit Join Date: Nov 2008 Posts: 8	I went to the link you posted. But all I saw was updates I couldn't ever find the actual copy.

27-07-2009, 20:15	#18
T'pek Second Lieutenant Join Date: Oct 2008 Location: Israel Posts: 118	Just noticed this topic listed on the main forum page. This looks very interesting. Is it open source? It'll be interesting to see a game coded in Java. Most games are done in C++, but using Java means you don't even have to make a different build for every platform. And as for you Glorfindal: http://www.eclipse.org/downloads/ Eclipse is a very good development environment for Java (and other languages), and there most good others are built upon it.

27-07-2009, 20:18	#19
Peter Ebbesen the Conqueror Join Date: Mar 2001 Location: Beyond the infinite Posts: 12,607	Glorfindal, the updates are the entire SDK, highest update number being latest revision. Just download the Java SE Development Kit 6u14. __________________ When I said: "Death Before Dishonour!", I meant it alphabetically. ----- For new denizens of the forum: To post here you have already agreed to follow the user agreement and the general rules (pay specific attention to rules 2, 3, and 6 if writing while your temper is heated). Furthermore, there may be special rules for specific forums. These can usually be found in sticky posts at the top of a forum. Read the stickies and obey the rules and, overall, it is a much nicer forum for all of us. Disobey the rules and be moderated, warned, put on probation, or banned.

27-07-2009, 20:43	#20
Glorfindal Recruit Join Date: Nov 2008 Posts: 8	Thanks both of u but is there any version of eclipse for Windows?